ts_paint depends on the first MozAfterPaint in the content window, not in the
browser as I had thought. After MozAfterPaint, it pings the parent process and
waits for a response (see `TalosPowers.loadPromise`), and then it ends. It will
wait up to 500ms for the response before timing out. Source:
https://dxr.mozilla.org/mozilla-central/source/testing/talos/talos/startup_test/tspaint_test.html
At first I modified UrlbarProviderSearchTips to wait on
`browser-delayed-startup-finished`, but the jsm kept appearing in ts_paint
profiles, and that's how I found out the above. So that's not sufficient.
There's already a promise in browser.js for waiting on the first paint in the
first content window, but it's "private." I added a public getter for it and
changed the name so it's clearer that it's related to the first content window,
not the browser window.
I also added a 500ms timeout just like the worst case in ts_paint.
Both checks (paint and the timeout) are done for a particular browser window
only the first time UrlbarProviderSearchTips sees it.
Finally, UrlbarProviderSearchTips can avoid importing BrowserWindowTracker
during startup by having browser.js pass the window to its `onLocationChange`. I
saw the BrowserWindowTracker.jsm import in some profiles while working on this.
With these changes, UrlbarProviderSearchTips no longer appears in ts_paint
profiles when I run it locally -- except when it is imported by
UrlbarProvidersManager, which ultimately happens due to setting the placeholder
text in the urlbar input. But even that doesn't appear in every profile.
I've also included the reordering of checks from a previous version of this
patch. That's still worth doing in general even if it's no longer relevant to
ts_paint.
Differential Revision: https://phabricator.services.mozilla.com/D80799
Rather than sending the strings down to the content process and back up instead
have the content process just send the media type which when prefixed with
`media-` gives us the fluent ID for the string. Ideally this would allow us to
just set that as the `data-l10n-id` for the items but since this tree is
generated by a custom `nsITreeView` implementation that isn't an option so this
still caches the strings on load.
A single formatValues call will be more performant.
Differential Revision: https://phabricator.services.mozilla.com/D77897
This allows the correct article to be displayed even when the reader mode ends up using a different process than the original page,
Differential Revision: https://phabricator.services.mozilla.com/D78487
This changes both the spellchecker parent code that interfaces with the
InlineSpellCheckerParent actor, and the child code interfacing with the
ContextMenuChild actor, to ensure they get notified when either actor
goes away.
It maintains the "uninit" messages to clear out spellcheck data when the
context menu goes away (while the window / actors remain intact).
It also adds some belts-and-suspenders type checks that allow us to
recover if we ever get in a bad state again, instead of stubbornly
throwing exceptions and breaking the UI for users.
Differential Revision: https://phabricator.services.mozilla.com/D75228
This changes both the spellchecker parent code that interfaces with the
InlineSpellCheckerParent actor, and the child code interfacing with the
ContextMenuChild actor, to ensure they get notified when either actor
goes away.
It maintains the "uninit" messages to clear out spellcheck data when the
context menu goes away (while the window / actors remain intact).
It also adds some belts-and-suspenders type checks that allow us to
recover if we ever get in a bad state again, instead of stubbornly
throwing exceptions and breaking the UI for users.
Differential Revision: https://phabricator.services.mozilla.com/D75228
This is the same preference that will power the notification suppression
option in bug 1635257, hence the preference name.
Differential Revision: https://phabricator.services.mozilla.com/D74941
This is the same preference that will power the notification suppression
option in bug 1635257, hence the preference name.
Differential Revision: https://phabricator.services.mozilla.com/D74941
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
After the recent simplifications to the zoom code, they only take care
of forwarding the enlarge / decrease zoom messages.
We can do that via PBrowser instead, and get rid of the actors. We can
also remove ZoomChangeUsingMouseWheel. Zooming with the mouse wheel will
end up in a *ZoomChange event anyways, and the only consumer already
listened for them.
Differential Revision: https://phabricator.services.mozilla.com/D73175