1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
There's still some potential work to do for layout-dependent shorthands, but I
believe given there's only progressions here this is worth doing.
Differential Revision: https://phabricator.services.mozilla.com/D132286
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Keeping the pref as signed, since the existing code explicitly handles that case, so someone may have -1 as the pref value.
Differential Revision: https://phabricator.services.mozilla.com/D132020
1. When we see a failed TRR lookup in nsHostResolver::CompleteLookup, we trigger
a Confirmation and retry the lookup.
2. When triggering Confirmation, we set LOAD_FRESH_CONNECTION on the TRR channel,
which will then tell the connection manager to clear out the current TRR conneection.
This will cause us to use a new connection for the Confirmation and subsequent
lookups.
Differential Revision: https://phabricator.services.mozilla.com/D129227
Keeping the pref as signed, since the existing code explicitly handles that case, so someone may have -1 as the pref value.
Differential Revision: https://phabricator.services.mozilla.com/D132020
It's only meaningfully read in two places:
* WebRender fallback code.
* Some widget DEBUG-only code, which on Linux is ifdef'd and on Windows does
some rather sketchy things like sleeping for 30ms
So I think it should be ok to remove, since WR fallback has its own flashing
pref as well, IIUC.
Differential Revision: https://phabricator.services.mozilla.com/D132313
`CreateElementTransaction` is too similar to `InsertNodeTransaction`. Only the
difference is, CreateElementTransaction::DoTransaction() creates an element via
editor instance and marks it dirty before inserting the new element. E.g.,
selection management and whether inserting new node or not at "redo" are same.
So, for the maintenance cost reason, we should get rid of
`CreateElementTransaction`, but for now, we should just make `HTMLEditor` use
`InsertNodeTransaction` instead, with a new pref to make it possible to back it
out the new behavior even after shipping.
Differential Revision: https://phabricator.services.mozilla.com/D132119
It is helpful if window visibility state could be checked by debug overlay.
For now, it works only on Windows with compositor.
Differential Revision: https://phabricator.services.mozilla.com/D131807
There's two kinds of test failures remaining:
* Failures related to how system colors inherit, which is something
that no engine is shipping and I'm not convince it's a good thing:
https://github.com/w3c/csswg-drafts/issues/6773
* Failures related to <iframes> observing color-scheme of ancestors
(which Chrome does implement but Safari doesn't):
https://github.com/w3c/csswg-drafts/issues/4772https://bugzilla.mozilla.org/show_bug.cgi?id=1738380
I'm unconvinced that should work across cross-origin iframes though
(see the question at the end of that issue), and it seems delaying
shipping it blocked on figuring that out while other engines ship
diverging behaviors is probably not worth it.
Given privileged code is already using this and we know of no other
blockers, I think it's fine to let it ride the trains.
Differential Revision: https://phabricator.services.mozilla.com/D131635
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
CLOSED TREE
Backed out changeset 511af4b42efc (bug 1734132)
Backed out changeset 9516eb1214d8 (bug 1734132)
Backed out changeset 513d740d6477 (bug 1734132)
As per spec. This could cause wrong styles to be returned because we
fill the bloom filter based on flat tree ancestors, which was ultimately
the root cause of bug 1737131.
Differential Revision: https://phabricator.services.mozilla.com/D131074
This means that more precise values can be stored, so that they match what we
actually retrieve from the printer and use in layout.
Depends on D99806
Differential Revision: https://phabricator.services.mozilla.com/D99807
Unfortunately this is not currently maintained (it's been broken
since the addition of sub_slice compositor surface support).
It's also complicating efforts underway to refactor the way that
picture cache dependencies are handled as part of the visibility
pass refactoring work.
For these reasons, let's remove this functionality. If we find
someone with time to maintain it in future, it's likely that we
could restore most of the viewer code, and update the picture
cache code in WR to output the appropriate information.
Differential Revision: https://phabricator.services.mozilla.com/D131105
In some platforms (like macOS, windows dark mode, android, and some gtk
themes) the foreground selection color might be `currentcolor`, and that
doesn't generally guarantee enough contrast with the attention
background.
Remove HeadlessLookAndFeelGTK's handling of this color since it's
useless (always overridden by prefs in all.js)
Differential Revision: https://phabricator.services.mozilla.com/D130617
This mainly provides DrawTargetWebgl, which implements the subset of the DrawTarget
API necessary for integration with CanvasRenderingContext2D. It translates them to
suitable commands for its internal ClientWebGLContext, which then manages remoting
WebGL requests to the parent/GPU process.
Currently two shaders are used for drawing Canvas2D primitives, but can be expanded
in the future. These are an image shader and a solid color shader.
The core of this implementation revolves around TexturePacker and TextureHandle,
which cope with the necessity of frequently uploading SourceSurfaces for use with
WebGL. TexturePacker implements a bin-packing algorithm for packing these uploads
into texture pages, which can either be SharedTextures if they are reasonably small,
or StandaloneTextures if they are too big to pack in a SharedTexture. Each upload
is assigned a TextureHandle which is used to manage it in a move-to-front cache,
so that we can easily eject TextureHandles from the back of the cache if we have
too many. These TextureHandles are associated with the SourceSurface that spawned
them to more easily manage their lifetimes.
There are further dependent caches for dealing with blurred shadows and with text.
Shadows are cached in an uploaded texture bound to the SourceSurface that generated
them. Text is handled by caching entire runs in the GlyphCache (keyed by both their
rendering parameters and their glyphs). The text is first rasterized to a surface
and then uploaded to a texture in the GlyphCache which can be reused should the
text be encountered again.
To deal with commands we can't accelerate, a separate internal DrawTargetSkia is
also maintained. The content of the WebGL framebuffer is copied into it so that
drawing can then proceed in software from there. It remains in this fallover state
until the next frame, when it resets back to using the WebGL framebuffer again.
This acceleration is disabled by default. To enable it, you must toggle the pref
"gfx.canvas.accelerated" to true. This should be suitably different from the naming
of the previous SkiaGL prefs to not alias with them. There are a few dependent prefs
that follow from the previous SkiaGL prefs for setting the size limitations for
acceleration and also limitations for the internal texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D130388
This mainly provides DrawTargetWebgl, which implements the subset of the DrawTarget
API necessary for integration with CanvasRenderingContext2D. It translates them to
suitable commands for its internal ClientWebGLContext, which then manages remoting
WebGL requests to the parent/GPU process.
Currently two shaders are used for drawing Canvas2D primitives, but can be expanded
in the future. These are an image shader and a solid color shader.
The core of this implementation revolves around TexturePacker and TextureHandle,
which cope with the necessity of frequently uploading SourceSurfaces for use with
WebGL. TexturePacker implements a bin-packing algorithm for packing these uploads
into texture pages, which can either be SharedTextures if they are reasonably small,
or StandaloneTextures if they are too big to pack in a SharedTexture. Each upload
is assigned a TextureHandle which is used to manage it in a move-to-front cache,
so that we can easily eject TextureHandles from the back of the cache if we have
too many. These TextureHandles are associated with the SourceSurface that spawned
them to more easily manage their lifetimes.
There are further dependent caches for dealing with blurred shadows and with text.
Shadows are cached in an uploaded texture bound to the SourceSurface that generated
them. Text is handled by caching entire runs in the GlyphCache (keyed by both their
rendering parameters and their glyphs). The text is first rasterized to a surface
and then uploaded to a texture in the GlyphCache which can be reused should the
text be encountered again.
To deal with commands we can't accelerate, a separate internal DrawTargetSkia is
also maintained. The content of the WebGL framebuffer is copied into it so that
drawing can then proceed in software from there. It remains in this fallover state
until the next frame, when it resets back to using the WebGL framebuffer again.
This acceleration is disabled by default. To enable it, you must toggle the pref
"gfx.canvas.accelerated" to true. This should be suitably different from the naming
of the previous SkiaGL prefs to not alias with them. There are a few dependent prefs
that follow from the previous SkiaGL prefs for setting the size limitations for
acceleration and also limitations for the internal texture cache.
Differential Revision: https://phabricator.services.mozilla.com/D130388
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
Behind a pref for now. Given these selectors do nothing on non-chrome
documents (they just don't match) it seems worth trying.
A cursory search seems to indicate they're not used for UA detection or
something like that (or at least I haven't found such an usage).
Differential Revision: https://phabricator.services.mozilla.com/D130736
Behind a pref for now. Given these selectors do nothing on non-chrome
documents (they just don't match) it seems worth trying.
A cursory search seems to indicate they're not used for UA detection or
something like that (or at least I haven't found such an usage).
Differential Revision: https://phabricator.services.mozilla.com/D130736
If GL is threadsafe, we can run on the compositor thread. This appears
to have performance benefits, possibly because the renderer thread is
too busy. If GL is not threadsafe, we must run the WebGL OOP instances
on the renderer thread.
At the time of writing, only the nouveau drivers on Linux are considered
to be not threadsafe, so most users will see WebGL running on the
compositor thread. This patch also adds prefers to override the
blocklist to either assume GL is threadsafe
(webgl.threadsafe-gl.force-enabled) and not threadsafe
(webgl.threadsafe-gl.force-disabled).
Differential Revision: https://phabricator.services.mozilla.com/D130634
The preference should be enabled before rolling out "fission for authenticated sites"
to makes sure we have the permissions there when the feature is on.
Differential Revision: https://phabricator.services.mozilla.com/D127107
Right now, all high-value permissions have the same expiration time, but
we might want to set difference expiration time for different
high-value permission type in the future.
Differential Revision: https://phabricator.services.mozilla.com/D127106
The telemetry result is written in bug 1706266 comment 1:
https://bugzilla.mozilla.org/show_bug.cgi?id=1706266#c1
`increasefontsize`, `decreasefontsize`, `gethtml`, `heading` and `readonly` are
obviously not used by web apps in the wild. Therefore, they can be disabled
in all channels.
`contentReadOnly` and `insertBrOnReturn` are odd. The usage is really low (less
than 1% of beta users). However, the number of documents which used the command
is about 1k samples. The result of the commands are not tiny (making the editor
not editable or changing the behavior at typing `Enter` key in `<div>`, `<p>`,
etc). Therefore, it's hard to use them in web apps which supports not only
Gecko. So I guess that they are collected the number of used by automated
tests of somebody because of the constant number in other beta versions.
Perhaps, we should disable it only in Nightly channel for now, and after a
couple of releases, we should try to disable those commands too later.
Depends on D130328
Differential Revision: https://phabricator.services.mozilla.com/D130329
Nihanth Subramanya
Noemi Erli
criss
kriswright
Csoregi Natalia
Emilio Cobos Álvarez
Jonatan Klemets
Alexandru Michis
Gabriele Svelto
Chris Peterson
Narcis Beleuzu
Olli Pettay
Marian-Vasile Laza
sotaro
Anny Gakhokidze
Butkovits Atila
Tim Huang
Valentin Gosu
jake champion
Kershaw Chang
Sylvestre Ledru
Deian Stefan
Cristian Tuns
Masayuki Nakano
Jesse Schwartzentruber
Kagami Sascha Rosylight
Iulian Moraru
ssummar
Niklas Goegge
Manuel Bucher
Lars T Hansen
Sean Feng
Ting-Yu Lin
Paul Adenot
Bryce Seager van Dyk
Bob Owen
Steve Fink
Glenn Watson
Stephen A Pohl
Lee Salzman
Andrew Osmond
Randell Jesup
Dimi