It's possible to observe an element in the iframe while the
ResizeObserver object lives in the outer document, so we have to make
sure we also schedule the observer for all documents in the same
BrowsingContext tree.
Differential Revision: https://phabricator.services.mozilla.com/D119843
Some platforms, especially mobile, don't allow setting the window
rect. The capabilities are supposed to say when that's possible or
not, so we shouldn't try to set it when we're told it's not.
Differential Revision: https://phabricator.services.mozilla.com/D121751
We can reuse most of the implementation from Firefox, we just need to
ensure that the corect android options end up in the capabilities.
Differential Revision: https://phabricator.services.mozilla.com/D121750
This attempts to emulate the behavior of GetRecommendedRenderingMode without
actually calling it. In addition, it allows some Gecko-specific behavior
like overriding the render mode explicitly that allows some simplification
of the decision-making.
Inside GetRecommendedRenderingMode, natural is only allowed if <= 20 size.
This allows us to thus decide mostly based on whether the size is > 20 or
if an explicit mode was specified. In the remaining case where we need
to check a GASP table if available, we defer to the symmetric flag. If
there is no GASP, we assume natural.
Differential Revision: https://phabricator.services.mozilla.com/D122025
This patch doesn't change behavior. The "InProcess" version of this API (which
we're migrating to in this patch) is used to annotate GetCrossDocParentFrame()
callsites that have been vetted as being OK with the fact that this API returns
null at the boundary of a cross-origin iframe, if fission is enabled.
The call that's being migrated here is about propagating the NS_FRAME_IN_POPUP
state-bit into subframes that are nested inside of a popup. This bit is used to
detect cases where the display root frame is different from the document frame.
We don't need to propagate the bit across process boundaries, because the child
process will have its own display root frame, distinct from that of the parent
process. So we're OK to use the "InProcess" version of the API here.
Differential Revision: https://phabricator.services.mozilla.com/D113546
The bug was that the tooltip was only being shown for reader-mode-button-icon. The tooltip would show if you hovered right over the icon, and it would be undefined otherwise. This patch shows the tooltip regardless of the hover target. The other items on nodeToTooltipMap and nodeToShortcutMap are toolbarbuttons, so their icons are added in CSS and event handling always sees the parent node as the hover target. The reader mode button icon, however, is an <image> child of its parent. Either it or its parent could be hover targets. I considered added some handling in GetDynamicShortcutTooltipText along the lines of checking node.closest(reader-mode-button). I settled on just adding more entries to nodeToTooltipMap and nodeToShortcutMap since it's safer and easier to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D122126
This patch adds console message for disallowing relaxing default
referrer policy. The console message will only be reported if less
restricted policy has been set for cross-site requests. And it will use
different messages according to whether the restriction is enabled or
not.
Differential Revision: https://phabricator.services.mozilla.com/D121699
This will help me fix bug 1723160 by letting me add frecency values to Places
result payloads.
I tried to keep this simple and only do what was necessary to fix the bug. Of
course there's a lot more cleanup we could do, like skip the whole conversion
between match objects and UrlbarResults altogether by only creating
UrlbarResults in the first place, but I didn't want to scope creep into fixing
bug 1717511.
Differential Revision: https://phabricator.services.mozilla.com/D122022
This adds `browser.urlbar.experimental.hideHeuristic`. When true, the heuristic
is hidden in the view except for the search tip heuristic.
This is implemented as part of the larger prototype described in the JIRA ticket
(see the bug for a link) and some Slack conversation. There isn't much of a spec
in that ticket, and I think that's OK because we'd like to iterate on a
prototype and we're not sure yet how exactly the UX should work.
For example, should the heuristic always be hidden or only in certain cases?
This revision always hides it (except search tips), but it's easy to imagine
we'll want to introduce some more sophisticated logic. Or more simply we may
want to always show specific types of heuristics, like omnibox, as this revision
does for search tips.
The implementation works by excluding the heuristic in the view. Each heuristic
provider still creates their heuristics. When the view receives the heuristic,
instead of adding and selecting it, it calls `input.setResultForCurrentValue()`
so that the heuristic is set as the current result. When the user presses enter,
the input checks `experimental.hideHeuristic` and whether the current result is
a heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D121785
This is useful so that author rules for :autofill also work for the
autofill preview.
It also makes the UA sheet in forms.css simpler (otherwise we'd need to
tweak the selectors to put :-moz-autofill-preview everywhere we put
:autofill).
Depends on D122013
Differential Revision: https://phabricator.services.mozilla.com/D122014
The style system uses the changed bits to compute the old state, so if
it's inaccurate it might cause styles to be incorrectly invalidated.
This causes issues because with the next patch the autofill jsm
calls removeManuallyManagedStates(AUTOFILL), then
addManuallyManagedStates(AUTOFILL | AUTOFILL_PREVIEW), and if the input
didn't have AUTOFILL before we'd incorrectly detect it as not changing
with the next patch.
Also make them not virtual anymore since nobody overrides them. An
alternative to this would be to assert that we don't yet have the state
we're adding (or that we have the state we're removing), and handle it
in the callers. But this is a bit more convenient.
Differential Revision: https://phabricator.services.mozilla.com/D122013
This adds a few dereferences to the Baseline Interpreter, but is simpler and should
be faster for C++ accesses. It also simplifies/unblocks the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D121995
This replaces the JS_OFF_THREAD_CONSTRUCTOR MagicValue for off-thread constructors
with the same placeholder object we use for the prototype. These constructors
aren't used by off-thread parsing and handling this another way requires a lot
of complexity. With Stencil work the off-thread global will hopefully be removed
eventually.
Differential Revision: https://phabricator.services.mozilla.com/D121993
RegExpStaticsObject just stores the RegExpStatics. It might be possible to store
the RegExpStatics directly in the GlobalObjectData in a follow-up bug.
Depends on D121982
Differential Revision: https://phabricator.services.mozilla.com/D121983
