I don't think there's ever a way these should differ.
Got some include hell from removing ReferrerInfo.h from Document.h but
hopefully should be straight-forward to review.
Depends on D173154
Differential Revision: https://phabricator.services.mozilla.com/D173155
This API is temporarily available and useful for web app developers who want to
stop supporting Gecko specific join/split direction handling as soon as possible
and who do not want Mozilla block their release schedule by rescheduling of
shipping the new behavior. Additionally, adding this command allows web apps
detects whether Gecko supports the new behavior and whether it's enabled.
On the other hand, We don't want to ship opt-out API because it's hard to keep
maintaining the legacy behavior specific paths. Therefore, the command does
nothing if web app calls
`Document.execCommand("enableCompatibleJoinSplitDirection", false "false")` if
the new behavior is enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D172351
The default value for the target is Unknown, so all callsites
keep working.
We also add a Target value used for Document precomputation. This
value is enabled in RFP Lite mode, and allows us to precompute
ShouldRFP and cache it for faster computations later. (The later
computations will still check the Target, but won't need to do the
other expensive checks.)
Differential Revision: https://phabricator.services.mozilla.com/D170891
The default value for the target is Unknown, so all callsites
keep working.
We also add a Target value used for Document precomputation. This
value is enabled in RFP Lite mode, and allows us to precompute
ShouldRFP and cache it for faster computations later. (The later
computations will still check the Target, but won't need to do the
other expensive checks.)
Differential Revision: https://phabricator.services.mozilla.com/D170891
This is not very optimimal, but tracking spellchecking state in DOM tree is tricky because of multiple contentEditables and possibility to set spellcheck true/false anywhere etc.
At least this helps with the testcase quite a bit.
Differential Revision: https://phabricator.services.mozilla.com/D169870
The idea is that dumping the counter with the url all the time prevents
(or at least mitigates) races between different process.
This should allow to get the counters from local builds in a
semi-structured / easy to filter-and-parse way.
Differential Revision: https://phabricator.services.mozilla.com/D168469
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
Added WebIDL interfaces as per spec, added some necessary changes to support maplike and setlike structures to be accessed from C++.
Added `::highlight(foo)` pseudo element to CSS engine.
Implemented Highlight as new kind of `Selection` using `HighlightType::eHighlight`. This implies Selections being added/removed during runtime (one `Selection` object per highlight identifier), therefore a dynamic container for highlight `Selection` objects was added to `nsFrameSelection`. Also, the painting code queries the highlight style for highlight Selections.
Implementation is currently hidden behind a pref `dom.customHighlightAPI.enabled`.
Differential Revision: https://phabricator.services.mozilla.com/D164203
This change removes an unused member that was accidentally preserved
from an earlier version of the fix and also makes the argument to
`DOMIntersectionObserver::Update` a reference since it can never be null
and the method was not asserting that it wasn't.
Differential Revision: https://phabricator.services.mozilla.com/D167356
This issue isn't spec issue. This is a kind of web compatibility issue.
UA can require per-lock conditions to use screen orientation lock [*1]. Gecko
and Blink require full screen to allow screen orientation lock.
But, actually, both is different.
- Gecko requires fullscreen request is completed.
- Blink requires fullscreen request is pending or fullscreen is completed.
It means that the following script is worked on Blink, but Gecko doesn't
```javascript
element.requestFullscreen(); // <- Don't wait for completion
window.screen.orientation.lock("portrait");
```
YouTube etc don't wait for completion of fullscreen request to call
`screen.orientation.lock()` like this script. So I would like to change the
behavior like Blink for web compatibility.
Also, `screen.orientation.lock()` will return rejected promise if pending
fullscreen request is canceled.
To allow pending full screen request for per-lock condition, we should check
whether we have pending full screen request. If having it, we should wait for
the completion of full screen request.
*1 https://w3c.github.io/screen-orientation/#locking-the-screen-orientation
Differential Revision: https://phabricator.services.mozilla.com/D149036
When `element.requestFullscreen` is called, we dispatch small task via
`Document::AsyncRequestFullscreen`. But it doesn't append `FullscreenRequests`
to `PendingFullscreenChangeList` immediately. So if we want to check
whether we have pending full screen request, we have to run an event loop.
Although I would like to check whether we have pending full screen request for
`screen.orientation.lock` compatibility, since we don't append it to pending
list immediately, we don't have the easy way to detect it.
`RequestFullscreen` doesn't wait for the completion if it runs on content
process since `RequestFullscreenInContentProcess` doesn't wait for the result
of chrome event. If runs on chrome process, `RequestFullscreenInParentProcess`
is synchronous. So this change removes `AsyncRequestFullscreen` and simply
calls `RequestFullscreen`.
By not using AsyncRequestFullscreen, we will append `FullscreenRequests` to
pending list immediately, so we can check it without event loop.
Differential Revision: https://phabricator.services.mozilla.com/D163583
For this particular crash, I was not able to reproduce it locally.
However, based on the testcase, it looks like what happened was the
window is transitioning into a new document, and the synchronous XHR
causes the event loop to execute ObserveForLastRememberedSize. I think
it's safe to not creating the observer since we are inactivating
the document.
Differential Revision: https://phabricator.services.mozilla.com/D166192
Previosuly we'd only pass the `TRRService::ProviderKey()` into the content
process. But now we need the full domain for the error page in the content
process, so we now pass the full domain. The ChildDNSService now holds on
to the full domain, but calls into `TRRService` to update the key for
telemetry and returns that when necessary.
Depends on D164348
Differential Revision: https://phabricator.services.mozilla.com/D164642
Previosuly we'd only pass the `TRRService::ProviderKey()` into the content
process. But now we need the full domain for the error page in the content
process, so we now pass the full domain. The ChildDNSService now holds on
to the full domain, but calls into `TRRService` to update the key for
telemetry and returns that when necessary.
Depends on D164348
Differential Revision: https://phabricator.services.mozilla.com/D164642
