When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
Instead of forcing a sync layout flush every time the autocomplete popup is opened, this forces a less expensive sync style flush instead (see [diff profile](https://perfht.ml/2VKZF77)). This results in a 29% performance improvement in the time it takes to show the autocomplete popup on my machine (Bug 1619498; average time across 5 measurements for the _first time_ the popup is shown went from 45 ms down to 32 ms).
Other approaches that were considered to avoid any flushing:
* `windowUtils.getBoundsWithoutFlushing`: Unfortunately, `getBoundingClientRect` couldn't be replaced with `windowUtils.getBoundsWithoutFlushing`, because the previously computed width of the popup is `0` when it is first shown, due to it starting out hidden (i.e. `display: none`).
* `promiseDocumentFlushed`: This method is async while all of the surrounding autocomplete UI code is sync, so while it's not impossible, it would be difficult to implement a simple fix.
Differential Revision: https://phabricator.services.mozilla.com/D71254
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
Users have much better, easier alternatives, like
DOMWindowUtils.{loadSheetUsingURIString,removeSheet}, which we use to
replace the only caller that exists in mozilla-central (the editor
element, which loads EditorOverride.css).
This allows to clean up the style system and editor. There are other
callers in comm-central, but it seems they can switch to DOMWindowUtils
trivially, as the DOMWindowUtils APIs also use the system principal and
thus they can load any URL.
I'll make sure to give them some time with the migration and/or help
out of course.
Differential Revision: https://phabricator.services.mozilla.com/D71263
This patch introduces a new tab modal system prompt type. It can be opened via the nsIPromptService
with a destination BrowsingContext. These tab system prompts overlap slightly with the upper
chrome UI to differentiate them from content prompts (previously called tab prompts).
- Extended nsIPromptService and nsIPrompt to accept 3 types of modal prompts:
- Window prompts
- Tab (system) prompts
- Content prompts (the old tab prompts)
- Removed prompt code from Prompter.jsm, always call PromptParent window actor instead
- Added PromptChild window actor to forward pagehide events to parent actor
- Created additional prompt methods in nsIPromptService to prompt by browsingContext and modalType
- Backwards compatibility is maintained, consumers can still open content prompts calling nsIPrompt with a content window
Differential Revision: https://phabricator.services.mozilla.com/D66446
Implemecurnt a flag `suspendMediaWhenInactive` on the docShell that indicates media in that shell should be suspended when the shell is inactive. Currently, only GeckoView is using this flag.
---
The reason of implementing this flag is because in bug1577890 we remove the old way to suspend/resume the media, and I thought setting docshell to inactive is enough to suspend the media because we already have a mechanism which would suspend/resume media when document becomes inactive/active [1].
However, the active state of document is actually different from what I thought it was. Setting docshell to inactive won't change the document's active state, because that indicates if the document is the current active document for the docshell [2] (docshell can have multiple documents), instead of indicating if the docshell is active or not.
Therefore, we have to add another flag to indicate if the docshell wants to suspend its media when it's inactive, in order to use current mechanism to suspend/resume media.
[1] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/html/HTMLMediaElement.cpp#6453
[2] https://searchfox.org/mozilla-central/rev/4d2a9d5dc8f0e65807ee66e2b04c64596c643b7a/dom/base/Document.h#2627-2633
Differential Revision: https://phabricator.services.mozilla.com/D69669
--HG--
extra : moz-landing-system : lando
This code is used to determine the sizes of the top-level windows. However the
code doesn't cause quite desirable behavior (see the bug, and comment 15).
This patch does two things:
* Unifies the html / xul code-paths. This shouldn't change behavior (because
GetXULMinSize returns the fixed min-* property if present anyways), but
makes the patch a bit simpler.
* Makes the min-width of the XUL window be the pref size instead of the
min-size (for the cases where you have no explicit min-width). This looks a
bit counter intuitive, but it's the only way to guarantee that the content
will be shown. This matches the sizing algorithm that dialogs use by default
(via calling window.sizeToContent()), while allowing to undersize the window
via a fixed min-width property.
This in turn makes sizeToContent() work "by default" on XUL windows, avoiding
having to make JS listen to everything that possibly could change the layout of
the document (like resolution changes).
Differential Revision: https://phabricator.services.mozilla.com/D70209
--HG--
extra : moz-landing-system : lando
This is so that we can avoid needing mozSystemGroup (to get keypress for
non-printable keys), which in turn prevents racing with the native key event
listeners, see the second patch in bug 1624657.
This turned out to be a bit tricky, because we need to guarantee the ordering of
the search one-offs handling in the searchbar with the usual autocomplete-input
handling. We could try to move this to the popup subclass but this is already a
bigger patch than what I'd like.
We can also revert the customElements.js change I did in bug 1624657, as the bug
is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D69743
--HG--
extra : moz-landing-system : lando
Switch to `em` units to take font-size changes into account. This size works for one of the longer strings:
Restableix el &brandShortName; a l'estat inicial
Differential Revision: https://phabricator.services.mozilla.com/D70154
--HG--
extra : moz-landing-system : lando
This is so that we can avoid needing mozSystemGroup (to get keypress for
non-printable keys), which in turn prevents racing with the native key event
listeners, see the second patch in bug 1624657.
This turned out to be a bit tricky, because we need to guarantee the ordering of
the search one-offs handling in the searchbar with the usual autocomplete-input
handling. We could try to move this to the popup subclass but this is already a
bigger patch than what I'd like.
We can also revert the customElements.js change I did in bug 1624657, as the bug
is no longer relevant.
Differential Revision: https://phabricator.services.mozilla.com/D69743
--HG--
extra : moz-landing-system : lando
This removes the annotation from the following tests:
browser/base/content/test/general:
- browser_bug735471.js by removing the test
- browser_clipboard.js which seems like it's not using CPOWs anyway
- browser_blockHPKP.js which is disabled and isn't using CPOWs anyway
browser/components/customizableui/test:
- browser_934951_zoom_in_toolbar.js as CPOW usage was removed in bug 962248
toolkit/components/reader/test:
- browser_readerMode_with_anchor.js as CPOW usage was already removed in bug 1492482
toolkit/content/tests/browser:
- browser_datetime_datepicker.js as CPOW usage was removed in bug 1492482
- browser_saveImageURL.js which used deprecated CPOW-only APIs that I removed in an earlier cset
It also removes all the test framework code relying on this annotation.
Depends on D70685
Differential Revision: https://phabricator.services.mozilla.com/D70686
--HG--
extra : moz-landing-system : lando
This patch introduces a new tab modal system prompt type. It can be opened via the nsIPromptService
with a destination BrowsingContext. These tab system prompts overlap slightly with the upper
chrome UI to differentiate them from content prompts (previously called tab prompts).
- Extended nsIPromptService and nsIPrompt to accept 3 types of modal prompts:
- Window prompts
- Tab (system) prompts
- Content prompts (the old tab prompts)
- Removed prompt code from Prompter.jsm, always call PromptParent window actor instead
- Added PromptChild window actor to forward pagehide events to parent actor
- Created additional prompt methods in nsIPromptService to prompt by browsingContext and modalType
- Backwards compatibility is maintained, consumers can still open content prompts calling nsIPrompt with a content window
Differential Revision: https://phabricator.services.mozilla.com/D66446
--HG--
extra : moz-landing-system : lando
Since the test goes through all moz.build files disregarding DIRS and
the conditions that may disable directories, in some cases, moz.builds
can fail to be evaluated properly because of missing variables in
config.status. This time (because it's not the first), it's
LLVM_DLLTOOL.
After fixing that, it turns out many of the files/directories pointed to
by Files() directives were removed or moved.
While here, make the test script python3-ready.
Differential Revision: https://phabricator.services.mozilla.com/D70157
--HG--
extra : moz-landing-system : lando
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
This was generated with
```
cp .gitignore .rgignore
rg -l -g '*.{html,xhtml}' 'href="chrome://global/skin/"' | xargs sed -i "" 's/href\="chrome:\/\/global\/skin\/"/href\="chrome:\/\/global\/skin\/global.css"/g'
```
Differential Revision: https://phabricator.services.mozilla.com/D67687
--HG--
extra : moz-landing-system : lando
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
My patch causes an interesting regression. We stop constructing custom elements
for the stuff inside the edit-bookmark-panel as expected. This means that the
autocomplete-input here:
https://searchfox.org/mozilla-central/rev/3f9e822318e8ec18ce673a9cb983d3608a3e2ed2/browser/components/places/content/editBookmarkPanel.inc.xhtml#81
Doesn't cause autocomplete-input.js to load. That means that it'll load by the
time the searchbar-textbox autocomplete is created, which means that it'll get
upgraded asynchronously. So far so good. However there's an interesting race due
to the way keypress event listeners are setup in autocomplete-input.js. In
particular, it uses the capture phase and the system group:
https://searchfox.org/mozilla-central/rev/3f9e822318e8ec18ce673a9cb983d3608a3e2ed2/toolkit/content/widgets/autocomplete-input.js#38
This means it'll race with the other native / system group event listeners that
get added by the editor component. This caused arrow-up / arrow-down to not work
on the searchbar because the custom element was upgraded async.
This kinda papers over the issue the same way editBookmarkPanel was papering
over it, but ideally we should figure out a way to not use the system group or
keypress there so that we don't race in this awful way. Separate bug, probably.
Differential Revision: https://phabricator.services.mozilla.com/D69730
--HG--
extra : moz-landing-system : lando
Adds a new startup cache info service to expose some of the internal
state of the startup cache.
Differential Revision: https://phabricator.services.mozilla.com/D69298
--HG--
extra : moz-landing-system : lando
Adds a new startup cache info service to expose some of the internal
state of the startup cache.
Differential Revision: https://phabricator.services.mozilla.com/D69298
--HG--
extra : moz-landing-system : lando
It's only used to check whether the docshell is gone already, and we need to
deal with that in other places anyway. No other useful implementation.
In comm-central there are a couple, but they're useless too.
Differential Revision: https://phabricator.services.mozilla.com/D68731
--HG--
extra : moz-landing-system : lando
Nika Layzell
Bogdan Tara
Tim Nguyen
Brindusan Cristian
mhoye
Bianca Danforth
Kris Maglione
Ciure Andrei
Noemi Erli
Emilio Cobos Álvarez
Mike Conley
pbz
Csoregi Natalia
alwu
Stefan Hindli
Matthew Noorenberghe
Narcis Beleuzu
Gijs Kruitbosch
aarushivij
Mike Hommey
Oana Pop Rus
Emma Malysz
Kris Taeleman
Razvan Maries
Brian Grinstead
Cosmin Sabou
Itiel
Brendan Dahl
Mihai Alexandru Michis
Henri Sivonen
Dão Gottwald
Neil Deakin
Christoph Kerschbaumer
Mark Striemer
Dorel Luca
Julian
Arthur Iakab