Before this patch, nsISiteSecurityService APIs took "flags" parameters that
differentiated private contexts from not private contexts. However, these
parameters were redundant with respect to origin attributes, which led to some
confusion for consumers of these APIs. This patch removes these parameters in
favor of using origin attributes.
Differential Revision: https://phabricator.services.mozilla.com/D142901
This replaces all `instanceof` uses for DOM interfaces, since the operator in priviliged context works same as .isInstance().
Differential Revision: https://phabricator.services.mozilla.com/D141785
Otherwise we can return without the widget even seeing the event. This is how other test functions are implemented.
We need this to make the test in bug 1757928 pass.
Differential Revision: https://phabricator.services.mozilla.com/D142943
Discovered that Windows 32-bit was having trouble with the test case on the bug,
and figured that it might be preferable to limit chunk size to something more
constrained.
Differential Revision: https://phabricator.services.mozilla.com/D142512
This allows popups and sidebars to use the chrome preferred
color-scheme.
This moves the responsibility of setting the content-preferred color
scheme to the appropriate browsers to the front-end (via tabs.css).
We still return the PreferredColorSchemeForContent() when there's no
pres context (e.g., for display:none in-process iframes). We could
potentially move a bunch of the pres-context data to the document
instead, but that should be acceptable IMO as for general web content
there's no behavior change in any case.
Differential Revision: https://phabricator.services.mozilla.com/D142578
This removes the non-standard `hasInstance` proxy trap.
All objects will now use the algorithm in `JS::InstanceofOperator`. That function
uses other primitives and proxy traps already available to JS code.
As discussed in the bug, there's a minor difference in behavior: for
`xrayWrapper instanceof xrayWaiver` we used to always return false but we can now
invoke `xrayWaiver[Symbol.hasInstance]()`.
Differential Revision: https://phabricator.services.mozilla.com/D142061
Remember whether we have already de-duplicated them once and avoid doing
that again.
This is an alternative approach that doesn't add overhead to attribute
setting in the general case.
Differential Revision: https://phabricator.services.mozilla.com/D142813
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
Discovered that Windows 32-bit was having trouble with the test case on the bug,
and figured that it might be preferable to limit chunk size to something more
constrained.
Differential Revision: https://phabricator.services.mozilla.com/D142512
Make Link and SVGAElement agree on XLink handling, and make it more
explicit that SVGAElement needs to be a bit more special for SMIL.
Remove dead MathML XLink code.
Differential Revision: https://phabricator.services.mozilla.com/D142546
This is mostly edge-casey, but see bug 1757156 for an example where it's
causing some issues (granted, they could use `href="#"` or something
instead of an empty href).
It feels weird if a link looks like a link (because the CSS definition
of a link matches, which is "has an href") but then mostly doesn't
behave as a link.
We can't navigate anywhere if we don't have a valid URI but maybe JS
handles the relevant events as in bug 1757156.
Use the CSS definition (has href) since that's interoperable across
browsers. This should also make some stuff much faster (since checking
'is link' is now just a bit check instead of a virtual call).
(Awaiting try results, if no tests need adjustments then I need to write
some)
Differential Revision: https://phabricator.services.mozilla.com/D142107
This replaces all `instanceof` uses for DOM interfaces, since the operator in priviliged context works same as .isInstance().
Differential Revision: https://phabricator.services.mozilla.com/D141785
Note that we can probably use mLastRefreshDriverTime directly in
DocumentTimeline::GetCurrentTimeStamp(), i.e. we don't need to use the refresh
driver there, but I'd preserve the current behavior.
Differential Revision: https://phabricator.services.mozilla.com/D97823
This patch replaces the previous process selection infrastructure with a
new setup implemented entirely in C++, which should more accurately
track the set of processes in use, and should encourage re-use of the
existing content process when navigating by not counting the current
tab.
This approach intentionally allows for process switching to another
process during navigation if there is uneven load between processes to
encourage balanced process use.
I think this may also fix some of the session restore issues with many
tabs using the same process, rather than being spread over 4, as we now
track a tab earlier in its lifecycle before the BrowserParent instance
is created.
Differential Revision: https://phabricator.services.mozilla.com/D126405
This adds a virtual method to nsIGlobalObject and implements it for
nsGlobalWindowInner and SandboxPrivate. This means we don't have to put the
logic for dealing with all the different kinds of globals in once place.
Differential Revision: https://phabricator.services.mozilla.com/D141733
Jens Stutte
Norisz Fay
Dana Keeler
Kagami Sascha Rosylight
Ben Campbell
Timothy Nikkel
Matthew Gaudet
Peter Van der Beken
Tom Ritter
Butkovits Atila
Paul Zuehlcke
Emilio Cobos Álvarez
Jan de Mooij
Mike Conley
Edgar Chen
Caroline Cullen
Tom Schuster
Sean Feng
Manuel Bucher
Cristian Tuns
Gijs Kruitbosch
Rob Wu
criss
Hiroyuki Ikezoe
David Shin
Nika Layzell
Jon Coppeard