Now that windows is going to support dark colors, we want to make it
behave like other platforms in this regard.
Having a single pref for this seems better.
Differential Revision: https://phabricator.services.mozilla.com/D127624
For that:
* Tweak the standin system colors to match the non-native theme.
* Use those system colors for button and field backgrounds.
* Rename the "should use system colors" bit to "is high contrast",
which is what it really is (specially now that we use system colors
also in non-high-contrast).
Border colors and other colors like the <input type=range> and such
might need some extra tweaking perhaps, but this is a decent start and
looks good in https://crisal.io/tmp/form-controls.html afaict (dark mode
toggle needs the color-scheme pref enabled of course).
Differential Revision: https://phabricator.services.mozilla.com/D127533
In bug1692881, we introduced a mechanism to skip to next key frame if video decoding is too slow, which aims to help slow decoding issue on high resolution videos. Eg. 4k+.
However, there are some cases which would also lead to slow decoding. Eg. when internal seek (seek on one track only) happens on a place where we can't seek to directly, we need to seek to the previous keyframe and then decode all of them until we get the target frame.
That could lead to spending huge amount of time if the target frame is far from the keyframe, and causes decoded video frame later than the media time because audio won't stop playing during video seek. However, in above example, there would only be few frames later than the media time, and the video will soon catch up with the time.
As we only want to trigger this mechanism for continually slow decoding problem, and completely removing this mechanism would lead us fallback to the situation where some 4K+ videos would be frozen all the time during the playback.
In this patch, we introduce a method which still keep this mechanism but won't perform that as aggressive as before, this uses the time threshold to seek to the next keyframe when video has been late for too long.
Differential Revision: https://phabricator.services.mozilla.com/D126858
If amount of origins that have early-data disabled exceeds certain amount, disable early-data for all origins
This is controlled by prefs.
Differential Revision: https://phabricator.services.mozilla.com/D126555
There are a fair amount of performance and correctness issues that need
to be worked on, and at least I don't have the time to work on them
right now, so let's disable it until some of the issues blocking
bug 1578503 are fixed.
Differential Revision: https://phabricator.services.mozilla.com/D127085
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
`enterkeyhint` defines action label to present the enterkey of virtual
keyboard.
Actually, This attribute and setter/getter support on WebKit and Blink.
Even if desktop browsers (WebKit/macOS, Blink/Windows, Blink/macOS and
Blink/Linux) cannot set the enter key label on virtual keyboard, this is
supported.
So I would like to ship this to all platforms.
If this value is changed on desktop browser, it is unaffected.
Differential Revision: https://phabricator.services.mozilla.com/D126171
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
A couple of years ago we had observed that the way ANGLE emulated PBOs was slower than using glTexSubImage2D.
Since then ANGLE added a fast path which performs better, especially in frames with a large amount of pixels are uploaded.
Switching to PBOs on windows gives us better performance overall and will let us remove some code paths.
Differential Revision: https://phabricator.services.mozilla.com/D126697
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
Right now adding a dynamic pref for webrender involves plumbing in gfxPlatform, gfxVars, CompositBridgeParent, WebRenderBridgeParent, WebRenderAPI, the bindings, and then messaging the pref change to the right thread in WebRender.
That's quite a bit time consuming for something we tend to do for multiple things.
We already have a pretty good system for boolean debug prefs where the pref only needs to be listed in gfxPlatform and in the DebugPref enum of webrender_api/lib.rs, which has led us to use it for non-debug purposes.
This patch adds a system similar to the DebugFlags with values passed in a bitfield to be able to use gfxVars. In WebRender the parameters are key-value pairs which flow through the pipeline so that any component can react to them. A followup will add integer parameters.
The patch also moves a few prefs to this system and adds a pref to use PBO uploads.
Differential Revision: https://phabricator.services.mozilla.com/D126100