Summary:
document.addEventListener("shadowrootattached", e => {
// Do stuff with composedTarget.
});
I didn't bother to add tests for the event itself since this is going to get
tested in bug 1449333, but I can look into writing a chrome mochitest if you
want.
Test Plan: See above.
Reviewers: smaug
Bug #: 1470545
Differential Revision: https://phabricator.services.mozilla.com/D1777
MozReview-Commit-ID: 55cVMSsznMS
Summary:
This patch adds the infrastructure to move Activity Stream (about:newtab, about:home,
and about:welcome) into its own special content process - the privileged content
process. This feature of running Activity Stream in the privileged content process
is disabled by default. (See "browser.tabs.remote.separatePrivilegedContentProcess"
preference.) We can deal with other about: pages in a follow-up.
Reviewers: mconley
Tags: #secure-revision
Bug #: 1469072
Differential Revision: https://phabricator.services.mozilla.com/D1731
MozReview-Commit-ID: 5gIrP4LxcIt
--HG--
extra : rebase_source : d43c411ae60aad3d5a3a496e6729de0b547b4acd
Rename TOTAL_DOCGROUPS_PER_TABGROUP to
TOTAL_HTTP_DOCGROUPS_PER_TABGROUP, that collects telemetry for all
docgroups per tabgroup, but only for uris with http:// or https://
schemes.
Rename ACTIVE_DOCGROUPS_PER_TABGROUP to
ACTIVE_HTTP_DOCGROUPS_PER_TABGROUP, that collects telemetry for active
docgroups per tabgroup, but only for uris with http:// or https://
schemes.
We cannot simply pass the status code using nsIWebSocketListener::OnServerClose because it's called only when the connection is established. Instead, I'm passing TLS failure from http channel to nsIWebSocketListener::OnStop where the correct status code is set.
The probe is expired and there's no clear owner here so let's remove this
for now.
--HG--
extra : rebase_source : 51c332a790ce5081ce4645633991c3b9213a5d21
extra : source : 98d141e6d651b804cf35040a5c20be74b6fb6c7a
For number controls, nsContentUtils::IsFocusedContent doesn't really do the
right thing, because the thing it thinks is focused is the anonymous text
element inside the number control. As a result, we weren't properly updating
the state of the currently-focused number control when hitting enter in it to
submit the form.
The HTMLFormElement change is enough on its own to fix the bug. The constraint
validation change is a just-in-case.
I haven't figured out a sane way to write a reftest for this, unfortunately:
the enter key press needs to look like a real user event to trigger the
submission behavior.
It's possible that if the HTMLMediaElement is loading while we're loading a new
document into a docshell, that the HTMLMediaElement can reach readyState
HAVE_FUTURE_DATA just after its OwnerDoc is removed from the docshell. If the
HTMLMediaElement wasn't paused, then it may start playing due to the readyState
change in HTMLMediaElement::ChangeReadyState().
For years we've had hard to reproduce issues where media started playing after
we've closed the tab; I bet this was the cause!
When we detect that the document has been removed from its DocShell,
HTMLMediaElement::NotifyOwnerDocumentActivityChanged() is called, and that
suspends the MediaDecoder just in case we need to resurrect the media element,
for example if the tab comes out of the BF cache. When we suspend we set
mPausedForInactiveDocumentOrChannel=true, and all other calls to
MediaDecoder::Play() are guarded by checks on
mPausedForInactiveDocumentOrChannel.
So we should also guard the MediaDecoder::Play() call in ChangeReadyState()
with a check on mPausedForInactiveDocumentOrChannel too.
MozReview-Commit-ID: GfmZasT9jdr
--HG--
extra : rebase_source : dba32e8341a3dd70355ccdd7fd8790911a92acc8
extra : source : e94884022fa7df95adf90e44a44e4f168d60f01a
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 4f8dd2996d820fdb5a07afe544be5e2d6ca6a5c7
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 61afc5481dc8ec34caba1886bd74200cf3659fb4
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : b01f47e439a61492ad999ae30677c48535e8cd4c
The idea with this patch is that style code will first call
InlineStyleDeclarationWillChange before style declaration has changed, and SetInlineStyleDeclaration once it has changed.
In order to be able to report old attribute value, InlineStyleDeclarationWillChange reads the value and also calls AttributeWillChange (so that DOMMutationObserser can grab the old value). Later SetInlineStyleDeclaration passes the old value to
SetAttrAndNotify so that mutation events and attributeChanged callbacks are handled correctly.
Because of performance, declaration can't be cloned for reading the old value. And that is why the recently-added callback is used to detect when declaration is about to change (bug 1466963 and followup bug 1468665).
To keep the expected existing behavior, even if declaration isn't changed, but just a new declaration was created (since there wasn't any), we need to still run all these
willchange/set calls. That is when the code has 'if (created)' checks.
Since there are several declaration implementation and only nsDOMCSSAttributeDeclaration needs the about-to-change callback, GetPropertyChangeClosure is the one to initialize the callback closure, and the struct which is then passes as data to the closure.
Apparently we lost mutation event testing on style attribute when the pref was added, so test_style_attr_listener.html is modified to test both pref values.
--HG--
extra : rebase_source : 9e605d43f22e650ac3912fbfb41abb8d5a2a0c8f
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
I'm replacing non-failing calls to NS_NOTREACHED with MOZ_ASSERT_UNREACHABLE, but this NS_NOTREACHED fails when running the devtools/client/animationinspector/test/browser_animation_refresh_on_removed_animation.js test. This assertion failure is bug 1189015.
This patch DOES NOT fix the cause of the assertion failure (a missing TextNodeCorrespondenceProperty). It just replaces this failing NS_NOTREACHED with NS_ERROR because I can't replace with a fatal MOZ_ASSERT_UNREACHABLE.
MozReview-Commit-ID: H5rfyr71N1M
--HG--
extra : rebase_source : a65053171f41bc6069fc6cb3688c0a9cc36830b2
extra : intermediate-source : 203b3e7b091743faebcf58d576360d1afd85b6bc
extra : source : 12dcc693259a536ac06075698db7e851d682cf3a
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 571fd3b1e6511daa5731da76fb5d6d97bce11db1
Before this change, we don't acend up frame tree across different documents,
but it's possible that subframe document is scrolled out in the parent document,
if there are animations in such subframes, we should throttle the animations
too.
The test case added here fails without this fix.
MozReview-Commit-ID: EdOEVEwomPc
--HG--
extra : rebase_source : 4d6366cf609d9269ec05b3722f5adb21d940a9e3
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : 6b5101e05d2f0588e831c0a7d1239a3dcb65ddcb
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : 0e4d66fb7eab68c14fad10e3c5876bc491452e22
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : cb13b24696ee97b611c318b407ea9c31215df3f6
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : cb13b24696ee97b611c318b407ea9c31215df3f6
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : e473a7b0ec7c231ab321846c5ddcc4d6a88d7245
Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
Adding the Places* files into unified sources pushed the
unified sources into a situation that exposed a strangely
large number of errors. This seems to be the minimum set of
changes I could make to resolve all of the issues.
MozReview-Commit-ID: C2H9ce8FmE4
--HG--
extra : rebase_source : 7a3b71596b4318f517ec4c3ac0180e2aa3b721c7
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : 7e140df5961c5a01c13b1fd2489905f61c83959f
Originally, DisplayPort suppression was a process-global static. This change makes it possible
to control DisplayPort suppression on a per-PresShell basis.
Differential Revision: https://phabricator.services.mozilla.com/D1759
- Introduced the io.activity.enabled pref, so IOActivityMonitor can run without a timer
- Added IOActivityMonitor::NotifyActivities() to trigger notifications manually
- Added ChromeUtils.requestIOActivity() so we can trigger it via JS
MozReview-Commit-ID: 9JA2rLaM496
--HG--
extra : rebase_source : 0a92195b6b8314383c63de4b2bb1dfe033c40e9f
Re-creating a new demuxer is fine, provided that the SourceBufferResource exists. However, a resource is only created upon receiving an init segment.
The segment following a call to changeType() must be an init segment, will let the demuxer creation occurs there.
Differential Revision: https://phabricator.services.mozilla.com/D1812
On top of the two depending bugs.
Funny how there's a comment referencing bug 77999.
Differential Revision: https://phabricator.services.mozilla.com/D1750
MozReview-Commit-ID: LCuJROu92bo
On top of the two depending bugs.
Funny how there's a comment referencing bug 77999.
Differential Revision: https://phabricator.services.mozilla.com/D1750
MozReview-Commit-ID: LCuJROu92bo
This was a memory-saving optimization introduced as part of dependencies for bug
686875, but a more general system landed in bug 77999 for Gecko and
https://github.com/servo/servo/pull/18509 for Servo.
So now it's probably even a bit of a pessimization (though probably not huge),
and given this causes bugs like bug 1462742, bug 1157592, and bug 1468145, and
fishiness like the one pointed out in this bug, we may as well remove it.
The performance impact of having to lookup through more rules should be minimal
given the bloom filter and the rule hash optimizations.
This makes me wonder whether we could remove the whole concept of on-demand UA
sheets, since they've caused pain, for example, when the frontend people try
loading <svg>s from NAC (since that triggers sheet loading from frame
construction, which is not good). I'm not concerned about loading mathml.css and
svg.css everywhere, though xul.css may not be as doable since it adds a bunch of
attribute-dependent selectors. Though on the other hand I asserted in the
xul.css code and we don't load it in content with <video> / <input
type="date/time/etc"> and such, afaict, so maybe now that legacy addons are gone
we can remove that sheet from content processes altogether.
MozReview-Commit-ID: 9JCWNZj6BkT
This reduces memory usage because we only need one allocation instead of two
for the dynamic atom and its chars, and because we don't need to store a
refcount and a size. It precludes sharing of chars between dynamic atoms, but
we weren't benefiting much from that anyway.
This reduces per-process memory usage by up to several hundred KiB on my
Linux64 box.
One consequence of this change is that we need to allocate + copy in
DOMString::SetKnownLiveAtom(), which could make some things slower.
--HG--
extra : rebase_source : ba4065ea31e509dd985c003614199f73def0596c
SeekToNextFrame is handled differently than other seeks by the
MediaDecoderStateMachine, and should not take place while other seeks already
are. Bug 1410225 implemented some changes in HTMLMediaElement to prevent this,
but it's still possible to move to a seeking state in the MDSM and accept
SeekToNextFrame (as in this bug).
This changeset changes the MDSM to reject SeekToNextFrame if a seek is already
happening. Since the MDSM now does this the changes from bug 1410225 can be
removed.
This has the functional change of the promise from SeekToNextFrame being
rejected if the seek in not performed due to another seek. Previously the
promise would succeed when the other seek completed. This seems sensible as the
next frame seek does not actually take place.
MozReview-Commit-ID: HD9WRFq3LZV
--HG--
extra : rebase_source : fb276010119038db4319b3b81bcbf51ef2cab1d9
They require destructor of Animation, but that is an incomplete type in
AnimationEffect.h, and AnimationEffect.h cannot include Animation.h
because the latter already includes the former.
MozReview-Commit-ID: AunD7dI1QN5
--HG--
extra : rebase_source : c9331eb5186b09666419e0b7ab12517beb07793f
Some InputContext members are not forwarded through
PBrowser::SetInputContext.
MozReview-Commit-ID: C1bGYq4w8zT
--HG--
extra : rebase_source : 1481f08c7593fe9dceb3b96bbfe480a1c58ecf9d
We only build the frontend parts of Web Payments on Nightly, but users could
futz with the prefs and expose the DOM API on Beta. We should be careful about
not allowing that mismatch.
This also adds some additional logging if we run into a bug like this again.
MozReview-Commit-ID: 9qcQTIsIHkg
--HG--
extra : rebase_source : cdaed71d79e6f8cedd1229ffd03cac21e3660367
This patch puts the transformed pretty print DOM into a Shadow DOM.
The stylesheet is loaded with an @import in a <style> block, so the
monospace stylesheet had to be left out.
The XBL binding is kept, pending removal when Shadow DOM ships.
It's still needed to handle the case when Shadow DOM is pref'd off too.
MozReview-Commit-ID: DQRsXB8tumF
--HG--
extra : rebase_source : 6edc3d82392af4d98de454a5228328379a0fb7ee
The webauthn spec mandates that relying party identifiers (RP IDs) are valid
domain strings. This enforces that by ensuring that any passed-in RP IDs parse
correctly when set as the host portion of a URL.
https://w3c.github.io/webauthn/#relying-party-identifier
--HG--
extra : rebase_source : 6be22c9be660db3062f4e8119051cd122bc24a12
If we end up shutting down the content process while there's a request active
we'll end up "leaking" the request and asserting. This makes sure that we
let go of the PaymentRequest in that edge case. I can cause this by forceably
closing the payment request window on Linux without hitting OK or cancel.
MozReview-Commit-ID: 6XDYIcqNkC6
--HG--
extra : rebase_source : d20d8fae4aa4fc3afcca8491d415c64b8af8bcb4
Now uses StaticPrefs instead of DOMPrefs, and how we count dispatches for Workers.
MozReview-Commit-ID: DTumwcI5bG
--HG--
extra : rebase_source : 0cf5312e714fb260c01df647b2cd1fcc28ffc415