I've chosen this approach mainly because there's no other good way to guarantee
the model is correct than holding the snapshots alive until a style refresh.
What I tried before this (storing them in a sort of "immutable element data") is
a pain, since we call into style from the frame constructor and other content
notifications, which makes keeping track of which snapshots should be cleared an
which shouldn't an insane task.
Ideally we'd have a single entry-point for style, but that's not the case right
now, and changing that requires pretty non-trivial changes to the frame
constructor.
MozReview-Commit-ID: FF1KWZv2iBM
--HG--
extra : rebase_source : b02d516ea164fc567110338411bf6ba251d53dab
The part is mainly to set urgent-start for loading media when it's initiated by
user interaction. For the HTMLMedia element, it has its algorithm to pre-load
the media and users will get feedback once they play the media. Thus, I only
set urgent-start when the media element has autoplay attribute since the sooner
enough resource is loaded the sooner the media will be played.
MozReview-Commit-ID: 7nu3PUt8iYo
--HG--
extra : rebase_source : f1abfecdccb74f4ec79a057534c2e9a1bfd5ae41
Since RefPtr<T>&& can't be converted to T* implicitly, we need to change
T* to RefPtr<T> in resolve/reject callbacks to make it compile again.
We should review the changes later to look for the opportunity to
optimize away unnecessary AddRef/Release pairs.
MozReview-Commit-ID: 22rHQ8dhxJv
--HG--
extra : rebase_source : 1b09f353d6e86d60c93a2746333585ec0dba8526
Actually, we use GetValue to check whether value is empty or not for placeholder. But since GetValue uses TextEditor::OutputToString when on editor, it is expensive. Since editor has DocumentIsEmpty method, we should use it for this case.
MozReview-Commit-ID: rQX8yjnWQz
--HG--
extra : rebase_source : 25ec89385d704f5c4d2d0a15021c2a59b0201983
This part is mainly to mark the channel as urgent-start if src related
attributes in HTMLImageElement and HTMLInputElement is set and the channel is
open due to user interaction. Unfortunately, we cannot just check the event
state just after creating channel since some loading image tasks will be queue
and execute in stable state. Thus, I store the event state in elements and
pass it to the place where create the channel.
MozReview-Commit-ID: GBdAkPfVzsn
--HG--
extra : rebase_source : 715352317b4b600f8a7f78b7bc22b894bb272d27
Create a test to guarantee current behaviors. We should only set urgent-start
when it is triggered by user input events rather the other events or no any
events.
MozReview-Commit-ID: 1ehiD3ua5Kl
MozReview-Commit-ID: H6bL8PpzijJ
--HG--
extra : rebase_source : ae66b05eded40907d690ac69ea37a739413b9e51
The MP4Reader class was removed in bug 1163486, replaced
by MediaFormatReader combined with MP4Demuxer. Bug 1175752
disabled the corresponding gtest, but as the underlying
object is gone, the test should be removed instead.
MozReview-Commit-ID: 7mU4Q98LtKA
--HG--
extra : rebase_source : 10b20e749321a50bac708c493badbdf32b41f859
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Should also update audio playing changed after resumed from page.
MozReview-Commit-ID: 66vuJJFeWN3
--HG--
extra : rebase_source : 06802b2e49f5e712a1d9fd34d4ae017995faaa75
Nobody uses them anymore. Therefore, we can remove them from the tree.
MozReview-Commit-ID: KTqCeI2eeFW
--HG--
extra : rebase_source : f3fc274f39c135af51245efd4c4aebbc4c49a61f
Raise the urgent-start flag in the ClassOfService when the Fetch and XHR are
triggered by user input events. The urgent-start classification will tell the
network requests scheduler to perform it with the highest priority and also
ignoring any parallelism or overall connection limits.
MozReview-Commit-ID: 2YavWbuFaln
--HG--
extra : rebase_source : 40f41d1a4b9e323c0cf5710c6d5f2a1e45e93076
Turns out that Chrome treats the robustness values as SW_SECURE_DECODE to mean
that SW_SECURE_CRYPTO is also supported. So we'd better follow suit...
MozReview-Commit-ID: 6J68IsSQhyL
--HG--
extra : rebase_source : 08baf83f0812f52670f1643e7e86ced0a0972f64
Since we now want to support APZ for remote frameloaders in popups, but do not
want to needlessly enable it in simple popup widgets which should never host
remote content, we need to prevent remote content from being loaded into those
popups.
MozReview-Commit-ID: WfjMC2p2eK
Currently, we only correctly support remote layer trees for frameloaders that
use the same layer manager as their document. Since we need to be able to host
remote <browser> content in popup widgets for remote WebExtensions, we need to
tie the frameloaders to the layer manager of their host element, rather than
the root layer manager for the document.
MozReview-Commit-ID: 4RCsamFBiQw
When dragging a `draggable=true` HTML DOM node, if no data is added to the
DataTransfer during the DragStart event, we currently cancel the drag. This is
inconsistent with Chrome's behaviour.
This patch adds a chrome-only (hidden from content) item to the DataTransfer:
application/x-moz-dummy-data. This data is added only when no other data has
been added to the DataTransfer, and the target of the dragstart event was a
draggable=true HTML DOM node.
This hidden node allows for the drag event to complete successfully, while
appearing the same as Chrome's behavior to content scripts.
MozReview-Commit-ID: HVqEr7aR6DD
1. Label ReleasingTimerHolder with SystemGroup since ReleasingTimerHolder
touches nothing related to the web content but releases the handle of
the BlobImpl object.
2. Name ReleasingTimerHolder for telemetry.
--HG--
extra : rebase_source : dce59a96780f8b8accbfcc7e6fb981d8446365eb
This patch is to label the runnables dispatched to main thread of the
content process.
The major changes in xhr are to replace DispatchTo{Current,Main}Thread and
replace NS_DispatchToCurrentThread with |mWorkerPrivate->DispatchToMainThread|
in which a DocGroup-specific EventTarget on main thread for worker.
NPN_PostURLNotify(file=true) is no longer supported in NPAPI.
MozReview-Commit-ID: 12JlYduC7R8
--HG--
extra : rebase_source : dc9bd752f74b727d003c1371211095bc6656b8d3
Note that this test never actually fails short of passing file parameter to
NPN_PostURLNotify actually causing the browser to crash. It can't distinguish
between the case when file is working or not.
MozReview-Commit-ID: 1G590ZWpHsE
--HG--
extra : rebase_source : c294bc109b893c81b6ee4c3114bb039eab77af08
This is an optional parameter that can be used to test streams via file. It may
be necessary to back out this change when NPAPI sandbox is completed as the
testplugin may no longer be able to access files.
MozReview-Commit-ID: FsYxhKKr4hS
--HG--
extra : rebase_source : 5ee413531b5b178c92a1d5cf5c2223e624e02296
NPN_PostURL(file=true) is no longer supported in NPAPI.
MozReview-Commit-ID: IyLJSj4bKRR
--HG--
extra : rebase_source : f684a634c649eb3bae4f802f43fe810d3d88f96b
Sometimes ptrStreamBuffer may not be null-terminated and random memory
areas get printed out when running MOZ_LOG=Plugin:5,PluginNPP:5,PluginNPN:5
MozReview-Commit-ID: 4cyDhukl1Tx
--HG--
extra : rebase_source : 5e7b762d9634b8902f441143994a13d241e29ea0
The new telemetry tag is for probing the best IPC message pre-allocate size to avoid
realloc overhead. We only count those message size which is greater than 4096.
This tag integrates IPC_MESSAGE_SIZE and MESSAGE_MANAGER_MESSAGE_SIZE2 which
have both expired.
MozReview-Commit-ID: GjvuidGJ7pz
--HG--
extra : rebase_source : 1da13b3f2b5b042d0445abd6051993e2fb317f93
AddBlocker() could fail during main thread shutdown. We should clear sInstance
on failure so next Register() calls can fail gracefully.
MozReview-Commit-ID: KiRRhO9ymbf
--HG--
extra : rebase_source : ed514f71f85c3d2f7ed6a8ee6f701ae131ec5962
extra : source : 1f379bcfc15b77cc89ee7a3a9e12e85f63a83524
There are two places doing prototype setup in old upgrade,
- If definition comes after JS reflector creation, CustomElementRegistry::Upgrade will do prototype swizzling.
- If definition comes before JS reflector creation, Element::WrapObject will set up the prototype.
The later one does SubsumesConsideringDomain, but the former doesn't not.
This patch is to fix the inconsistency, i.e. the former case should also do SubsumesConsideringDomain.
MozReview-Commit-ID: G3gVsaEa0YF
--HG--
extra : rebase_source : 5e2081e470473cd1a1f642a2dc693127cb9486ca
Takes functionality from NSSU2FToken/NSSU2FTokenRemote classes, and
moves it into a U2FSoftToken class. Leaves
NSSU2FToken/NSSU2FTokenRemote classes intact so as not to break U2F
API code (to be ported to async IPC in bug 1354330).
MozReview-Commit-ID: El2MCcYUrtE
Takes functionality that was in the WebAuthentication class that now
needs to be handled by the parent process, and moves it to the
U2FTokenManager singleton class. U2FTokenManager is created on the
PBackground thread during the first WebAuthn transaction, and manages
hardware access and transaction management for the lifetime of the
browser session. Patch also adds parent classes for WebAuthn IPC
protocol.
MozReview-Commit-ID: EnhgUTPdlMZ
Takes functionality once in the WebAuthentication DOM class that needs
to be handled by the content process, and moves it to a
singleton (per-content-process) manager class. This allows the
WebAuthn API to centralize management of transactions and IPC
channels. Patch also creates the child (content-process) classes for
WebAuthn IPC channels.
MozReview-Commit-ID: 6ju2LK8lvNR
Before the patch set for bug 1323339, WebAuthentication was managing
almost all content-side functionality for the WebAuthn API. This
would've made it difficult to support IPC, transaction interruption,
etc... This patch strips most of the functionality out of
WebAuthentication. The functionality will be moved to the
WebAuthnManager class in the next patch, for sake of review coherence.
MozReview-Commit-ID: 9Uup8NhLVBj
