This is mostly a lot of boilerplate based off the trackers category/subpanels.
I would like to do some code-de-duplication, especially in browser-contentblocking,
but I figured it would be a good idea to leave that to a different bug to not obstruct
the feature from landing :)
Differential Revision: https://phabricator.services.mozilla.com/D18826
--HG--
extra : rebase_source : d0fb21c5a42cf16dfe6b185806575f09e9a9f1a5
During security.sandbox.gpu.level=1, compositor window's parent cannot be set in GPU process, it needs to be set in UI process.
Differential Revision: https://phabricator.services.mozilla.com/D18811
When getting the cell-index object attribute, now take into account that the row index might be invalid, and bail if that's the case. This should prevent negative index values which were one of the causes of Occasional crashes on Linux with weirdly formed tables like in Gmail.
Differential Revision: https://phabricator.services.mozilla.com/D18546
--HG--
extra : moz-landing-system : lando
Copy fonts loaded during a mozPrintCallback into the cloned document,
so they are available during printing.
Differential Revision: https://phabricator.services.mozilla.com/D18613
--HG--
extra : moz-landing-system : lando
MOZ_ALWAYS_TRUE is only useful for expressions with necessary side effects. The
intent here was to check for this condition even in release builds.
Differential Revision: https://phabricator.services.mozilla.com/D16920
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEvent() discards or puts off to dispatch
the handling event if it's a keyboard event and event dispatching is
suppressed by the document.
This patch moves the block into the new method for making HandleEvent() simpler.
Differential Revision: https://phabricator.services.mozilla.com/D18520
--HG--
extra : moz-landing-system : lando
There are a few potential places to do this:
(1) UrlbarProviderUnifiedComplete, when it creates results
(2) UrlbarResult.payloadAndSimpleHighlights(), which UrlbarProviderUnifiedComplete calls when it creates results (and presumably other providers would call it, too)
(3) UrlbarResult._titleAndHighlights(), when it figures out what to return as the title
It's hard to do it in (3) because in that location, we don't know the user's search string, so we don't know what to highlight. (1) is possible, but it would probably be nice for other providers and all result types to benefit from this? So I chose (2), and also because UrlbarResult.payloadAndSimpleHighlights() is just an easy place to do it since UrlbarProviderUnifiedComplete calls it for each result it creates.
The actual code to get the domain is copied from autocomplete.xml more or less.
Differential Revision: https://phabricator.services.mozilla.com/D18642
--HG--
extra : moz-landing-system : lando
We should replace the context.autofillValue property with a result.autofill property. When the view selects results, it already notifies the input about it by calling input.setValueFromResult(). So we can modify setValueFromResult to check for the presence of result.autofill and thereby get autofill "for free".
result.autofill is an object: { value, selectionStart, selectionEnd }
This is going to help me implement bug 1521702.
One potentially cool thing about doing autofill this way is that any result can now trigger autofill, not only the heuristic result, and do it easily. Of course the user isn't typing when they select a non-heuristic result, so it's probably not fair to call that "autofill", but the result can trigger the selection aspect of autofill. As one example, that might be interesting for search suggestions: Type "foo", key down to the "foobar" suggestion, and the "bar" substring is automatically selected.
Differential Revision: https://phabricator.services.mozilla.com/D18618
--HG--
extra : moz-landing-system : lando
Specifically, we make adjustments to the transform used for:
- layers with the RCD-RSF APZC
- the async zoom container layer
- layers fixed w.r.t the RCD-RSF
Differential Revision: https://phabricator.services.mozilla.com/D18114
--HG--
extra : moz-landing-system : lando
The end result we want is that on the web cross-compartment wrappers for
WindowProxy and Location are always CrossOriginObjectWrapper. That needs to be true
for both cases that are different-origin (as now) and cases that are
same-origin, since they might become different-origin due to document.domain
changes but we don't want that to affect the wrappers involved.
On the web, all security checks are symmetric, so in WrapperFactory::Rewrap we
would have originSubsumesTarget == targetSubsumesOrigin in all web cases.
I claim that
originSubsumesTarget == targetSubsumesOrigin &&
(!targetSubsumesOrigin ||
(!originCompartmentPrivate->wantXrays &&
!targetCompartmentPrivate->wantXrays)) &&
"object is a WindowProxy or Location"
is a necessary and sufficient condition for using CrossOriginObjectWrapper.
Comparing to our current code, if originSubsumesTarget and targetSubsumesOrigin
are both false, then for the WindowProxy and Location cases we currently end up
with the following arguments to SelectWrapper:
securityWrapper: true
xrayType: XrayForDOMObject
waiveXrays: false
So SelectWrapper ends up returning CrossOriginObjectWrapper, which the new
condition keeps doing.
If originSubsumesTarget and targetSubsumesOrigin are both true, then there are
two cases. If both compartments have wantXrays false (which is always the case
on the web), then we end up with the following arguments to SelectWrapper:
securityWrapper: false
xrayType: NotXray
waiveXrays: false
and SelectWrapper returns CrossCompartmentWrapper. We want to do
CrossOriginObjectWrapper instead, as explained above.
Finally, if originSubsumesTarget and targetSubsumesOrigin are both true but one
of the compartments has wantXrays set, then we get:
securityWrapper: false
xrayType: XrayForDOMObject
waiveXrays: might be true or false
and then SelectWrapper might return a WaiveXrayWrapper or a PermissiveXrayDOM.
In this case we do _not_ want to start returning CrossOriginObjectWrapper, and
this is a non-web case anyway, since web compartments can't set wantXrays.
Differential Revision: https://phabricator.services.mozilla.com/D18030
--HG--
extra : moz-landing-system : lando
There's a crazy driver bug here on Mac+Intel, but if we're forbidding it
there, why not everywhere.
It's optional in EXT_color_buffer_half_float for webgl1, and no allowed by
EXT_color_buffer_float for webgl2 anyway.
MozReview-Commit-ID: kI9DUj8TU8
Differential Revision: https://phabricator.services.mozilla.com/D18769
