Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
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
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
This ensures that chrome code can always react to the state the browsing
context the parent process observes properly. It's also simpler.
We fix one test that was relying on the event being fired at the
browser. For the same reason as the previous patch in this bug, we can
use resize events instead.
Differential Revision: https://phabricator.services.mozilla.com/D72712
Add importableLogins autocomplete items that show for a site when there's chromium-based logins, no saved logins, and appropriate experiment state. Default behavior is unchanged with default "" pref value, and new behavior can be turned on with "import" pref value.
Differential Revision: https://phabricator.services.mozilla.com/D72096
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
Dão Gottwald
David Teller
Bogdan Tara
Jonathan Watt
Ed Lee
Emilio Cobos Álvarez
Ian Moody
Stefan Hindli
Dorel Luca
Bianca Danforth
Andreea Pavel
pbz
Gijs Kruitbosch
Noemi Erli
Matt Woodrow
Edgar Chen
Csoregi Natalia
Neil Deakin
Nika Layzell
Cosmin Sabou
Chris H-C
Mike Conley
Gurzau Raul
Tim Nguyen