We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
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
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
This API is no longer possible to implement, as it will always try to set the
OriginAttributes on a content BrowsingContext after it has been attached, and JS
can never observe a detached BrowsingContext.
Users of this API are instead changed to perform assertions that
originAttributes have already been set correctly.
Differential Revision: https://phabricator.services.mozilla.com/D67046
--HG--
extra : moz-landing-system : lando
And rename GetRenderLabel to GetRenderedLabel, as it's a slightly more
descriptive name IMHO.
Differential Revision: https://phabricator.services.mozilla.com/D69837
--HG--
extra : moz-landing-system : lando
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Differential Revision: https://phabricator.services.mozilla.com/D63545
--HG--
extra : moz-landing-system : lando
Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
however this could cause issues when the tab containing the PWindowGlobal was
being destroyed. Due to the slightly different lifecycles of the PBrowser actor
and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
This patch moves PWindowGlobal to be directly managed by PContent, and changes
logic which previously used `Manager()` to get `Browser{Parent,Child}` to
instead use a pointer member.
Differential Revision: https://phabricator.services.mozilla.com/D68596
--HG--
extra : moz-landing-system : lando
This API is no longer possible to implement, as it will always try to set the
OriginAttributes on a content BrowsingContext after it has been attached, and JS
can never observe a detached BrowsingContext.
Users of this API are instead changed to perform assertions that
originAttributes have already been set correctly.
Differential Revision: https://phabricator.services.mozilla.com/D67046
--HG--
extra : moz-landing-system : lando
According to spec, option elements with label attributes should show and use
those labels rather than their element text. So let's do that.
Requires some trickery because the option element is a block element (so it
lays out its width based on its text content) so we put its label (if it has
one) in its ::before and skip frame generation so it measures the text of its
label, not of its text node children.
Differential Revision: https://phabricator.services.mozilla.com/D63545
--HG--
extra : moz-landing-system : lando
Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
however this could cause issues when the tab containing the PWindowGlobal was
being destroyed. Due to the slightly different lifecycles of the PBrowser actor
and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
This patch moves PWindowGlobal to be directly managed by PContent, and changes
logic which previously used `Manager()` to get `Browser{Parent,Child}` to
instead use a pointer member.
Differential Revision: https://phabricator.services.mozilla.com/D68596
--HG--
extra : moz-landing-system : lando
For now only record for password manager autocomplete but the event structure is setup to support others.
Differential Revision: https://phabricator.services.mozilla.com/D66730
--HG--
extra : moz-landing-system : lando
* To ensure it is only recorded the first time for a site per session, the event is recorded in the parent process.
* To ensure it is recorded any time the option could be displayed in the popup, there is a check everywhere AutoCompleteResultView.setResults gets called, since the 'results' object represents the options presented in the autocomplete popup, including the password generation option.
* AutoCompleteParent.showPopupWithResults
* This covers the case when 'results' changes, and the popup is not currently open.
* AutoCompleteParent.invalidate
* This covers the case when 'results' changes, and the popup is already open.
* Also removed some dead code (an extraneous if/else block) in showPopupWithResults.
Differential Revision: https://phabricator.services.mozilla.com/D65407
--HG--
extra : moz-landing-system : lando
When searching for the controller for a command in nsWindowRoot::GetControllerForCommand, look for a focused browsing context instead and get the controller through the Controllers actor associated with that browsing context. When a command update occurs in a window in the child process, send the list of commands to the parent process along with the browsing context for that window. The parent will pass this information to the controllers actor. As long as we can get the right currently focused browsing context descendant, we can get the correct command state and invoke commands through the right actor.
Differential Revision: https://phabricator.services.mozilla.com/D66222
--HG--
rename : toolkit/modules/RemoteController.jsm => toolkit/actors/ControllersParent.jsm
extra : moz-landing-system : lando
These methods were used for media control and audio focus on Fennec, and we don't need them anymore.
Differential Revision: https://phabricator.services.mozilla.com/D65262
--HG--
extra : moz-landing-system : lando
If a page has multiple videos, PiP keyboard shortcut opens the currently playing video.
Opens the first video, if no video is playing.
Differential Revision: https://phabricator.services.mozilla.com/D63780
--HG--
extra : moz-landing-system : lando
This replaces the handling of the ZoomChangeUsingMouseWheel event with
2 new zoom events that trigger the actual zoom changes. As a side effect,
this allows the mousewheel and zoom in/out key events to have an effect
on Reader and PDFJS views as well.
Differential Revision: https://phabricator.services.mozilla.com/D59260
--HG--
extra : moz-landing-system : lando
This patch was generated with a script. It doesn't include all files:
- Files that use the preprocessor or fail to parse are skipped
- Files that are loaded as JSMs but don't use the .jsm extension are skipped (those will be renamed in Bug 1609269)
It was generated with the following command using d855222aa2/no-this-property-read.js:
```
hg revert --all &&
cp .gitignore .rgignore &&
rg --files-without-match -g '*.jsm' '^#endif|^#include|^#filter' | jscodeshift --stdin --transform ~/Code/jsm-rewrites/no-this-property-read.js --ignore-pattern ./mobile/android/modules/Sanitizer.jsm --ignore-pattern ./js/xpconnect/tests/unit/syntax_error.jsm &&
./mach eslint `hg st | rg '^M ' | sed 's/^M //'`
```
Differential Revision: https://phabricator.services.mozilla.com/D60187
--HG--
extra : moz-landing-system : lando