When user adds and sets widget.workspace-management preference value, use it as override to restore windows on particular worspaces.
Differential Revision: https://phabricator.services.mozilla.com/D86205
AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this)
Most other users don't care about the size of these special scrollbars.
I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it.
Differential Revision: https://phabricator.services.mozilla.com/D85708
The existing calculation will make them overlap. The AdjustOverlappingScrollbars code was written with overlay scrollbars in mind but it looks like it will work just fine for this case.
Differential Revision: https://phabricator.services.mozilla.com/D85707
Otherwise the calculation above would lead to an empty rect for the scroll corner.
The scrollbar rects as computed now still overlap each other and the scroll corner, the next patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D85706
There is no dependency in this code as far as I can tell.
The next patch needs the scrollbar rects for the scroll corner calculation.
Differential Revision: https://phabricator.services.mozilla.com/D85705
Layout scrollbars that were only created for the visual viewport had no space reserved for them, so we need to shift them back in like overlay scrollbars. Otherwise they sit just outside of the scroll port and are not visible.
Depends on D85703
Differential Revision: https://phabricator.services.mozilla.com/D86332
For the former we are still allowed to show scrollbars if we need to scroll the visual viewport inside the layout viewport (as long as they take up no layout space). For the latter we still do not want to show scrollbars.
The ShowScrollbar enum is now only from layouts perspective and doesn't take into account anything about the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D85700
This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches.
The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport).
In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed).
Differential Revision: https://phabricator.services.mozilla.com/D85699
We want this to be turned on for nightly users by default. The page range is still a WIP,
so we should hide that section for now.
This also adds the pref to the "Nightly Experiment" panel, turned on by default.
Differential Revision: https://phabricator.services.mozilla.com/D85907
This can cause the URL preloader to think that initialization has succeeded
when it hasn't. This add observer call can fail if we're late in shutdown,
because the observer service still exists, but it isn't taking new
observers. I'm not sure how much it matters that we're failing to listen for
an observer that can't possibly fire at this stage, but a failure to check
for this seems to have contributed to the crash in bug 1656973, so we
might as well just fail.
Differential Revision: https://phabricator.services.mozilla.com/D86031
Some of the entry points into the URL preloader check sInitialized, and only
use it if it is true. However, if we're late in shutdown and we've already
cleared the singleton for the preloader then our failure to clear the
sInitialized flag means we'll recreate the preloader, which is going
to fail in various ways.
I think this won't help in the case of bug 1656973, because that seems
to go through AutoBeginReading, which unconditionally creates a new
singleton if one does not exist.
Differential Revision: https://phabricator.services.mozilla.com/D86030
This seems like a nice assertion to have so arrange that the weakref target is not set if registration fails. Also I fixed places where we didn't report out of memory on failure.
Differential Revision: https://phabricator.services.mozilla.com/D86186
Bogdan Tara
Christoph Kerschbaumer
Richard Sherman
Simon Fraser
Martin Stransky
alexandru.ionescu
Edgar Chen
Timothy Nikkel
Emilio Cobos Álvarez
Julian Descottes
Mihai Alexandru Michis
Thomas Daede
Marcos Cáceres
Brindusan Cristian
Emma Malysz
Daosheng Mu
Hiroyuki Ikezoe
Dave Townsend
Jeff Gilbert
Andrew McCreight
Matt Woodrow
André Bargull
Jon Coppeard
Simon Giesecke