Nvidia users will finally be able to use the superior display server

Good news for those who want to run their system Wayland only.

This is part of the Android release for Firefox 127.0.2.

Release notes

Please leave a comment on Bug : Android idle battery drain due to Firefox if you still experience this issue after updating Firefox and restarting your phone:

• Fixed an issue where YouTube playback may experience stalling under certain conditions.

• Fixed an issue where the Private Window icon was displayed in the taskbar on Windows when browser.privateWindowSeparation.enabled was set to false.

Luminance is a simple GTK application to control brightness of displays including external displays supporting DDC/CI

Here's the Github Repo

In the latest Mozilla Firefox 127 release simply do the following:

• Go to about:config in a new tab
• ‘Accept Risk and Continue’
• Search for browser.newtabpage.activity-stream.system.showWeather
• Double-click the result to enable the feature

This discussion on Mozilla Connect was updated today to include a demo video of the current progress of the addition of tabs in the sidebar.

Hi everyone,

We’re very grateful for your feedback during the beta testing and are happy to announce that automatic photo backup on iOS is rolling out now and will be available for everyone over the next few days.

Features

• Automatic backup that can be enabled to sync to the secure cloud at regular intervals
• End-to-end encryption of biometric data, geographic information, and other important metadata
• Save images in their original resolution
• Select any file, video, or photo to easily view them offline 
• Generate an encrypted file-sharing link with or without password protection for any photo or video, to share with anyone

Let us know what you think! You can also share, vote, and discuss feature requests on User Voice. Thank you, as always, for your feedback and support.

Proton Team

cross-posted from: https://lemdro.id/post/9940873

And this is 100% Youtube's fault, not Firefox's fault, they created this issue:

This problem is triggered by bad muxed VP9 bytestream served by Youtube, so it's not a regression on our side, this issue can also be reproduced on old versions Firefox. Usually when muxing a video bytestream, the video samples' timestamp should be monotonizally increasing and no overlap between samples. But there are some bad video samples in YT's bytesteam, they overlapped with the previous sample. Eg. [124416000, 125126000] and [125125000, 131382000]. The next one should start from 12516000 instead of starting from 125125000 causing an overlapping.

That overlapped sample triggers this and our WebM demuxer fails to calculate the next timestamp in that situation. The end time of video sample was set to the same as the sample's start time, and that causes a gap being detected for the next sample, resulting in resetting append state. When doing so, mNeedRandomAccessPoint would be set to true and that triggers the sample skipping mechanism per the spec.

Therefore, there would be many sample being incorrectly skipped and won't be added into the buffered range. When entering the buffering state, Firefox would be waiting those sample which has been skipped but Youtube thought that those samples were already appended. That makes the endless buffering happened.

Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1878510#c113 (Alastor Wu [:alwu])

And this is 100% Youtube's fault, not Firefox's fault, they created this issue:

This problem is triggered by bad muxed VP9 bytestream served by Youtube, so it's not a regression on our side, this issue can also be reproduced on old versions Firefox. Usually when muxing a video bytestream, the video samples' timestamp should be monotonizally increasing and no overlap between samples. But there are some bad video samples in YT's bytesteam, they overlapped with the previous sample. Eg. [124416000, 125126000] and [125125000, 131382000]. The next one should start from 12516000 instead of starting from 125125000 causing an overlapping.

That overlapped sample triggers this and our WebM demuxer fails to calculate the next timestamp in that situation. The end time of video sample was set to the same as the sample's start time, and that causes a gap being detected for the next sample, resulting in resetting append state. When doing so, mNeedRandomAccessPoint would be set to true and that triggers the sample skipping mechanism per the spec.

Therefore, there would be many sample being incorrectly skipped and won't be added into the buffered range. When entering the buffering state, Firefox would be waiting those sample which has been skipped but Youtube thought that those samples were already appended. That makes the endless buffering happened.

Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1878510#c113 (Alastor Wu [:alwu])

I still can't believe how this one comes back again and again. One of the greatest feat of humanity.