Merge "DOMServiceWorkerFocusClient" & "DOMWebNotificationClicked"
to "DOMWindowFocus" event. Utilize the event to switch tab when
loading links to an existing target tab.
MozReview-Commit-ID: Hd1NkVkrJA1
I want to remove nsIDOMNodeList usages from editor excepting old debug code.
(BTW, we might have to change to <meta charset> instead of <meta http-equive>, but it should handle by another issue)
MozReview-Commit-ID: ArAVOHigKNW
--HG--
extra : rebase_source : 74ddcaa760c0cc80d6395acb3a6c9374a80dec25
extra : histedit_source : f582131f2b1d5cca8b024b0936ad04634566014e%2Ce95119c3c80903588b24fc66cd6a5b3a8e1458a9
For animated images with finite animations we can finish running their animation. At which point we won't call RequestRefresh, and so we will never mark the composited frame as valid (since that is the only place we do that).
To fix this we mark the composited frame as valid when we finish decoding.
But we can do better than that, we can mark the composited frame as valid immediately when we create a new decoded since we are just drawing the final frame from now on.
Bug 1344892 - 1. Add option to dispatch to priority queue; r=snorp
For the regular "gecko" option, change to dispatching to the XPCOM event
queue, and add a new "gecko_priority" option that dispatches calls to
the widget event queue. GeckoThread.waitOnGecko is changed to wait on
both the widget queue and the XPCOM queue. nsAppShell::SyncRunEvent is
changed to avoid a possible deadlock condition involving locking
sAppShellLock twice.
Bug 1344892 - 2. Update dispatchTo = "gecko" options; r=snorp
Update some existing dispatchTo = "gecko" options to "gecko_priority",
which typically involve UI events or JNI management calls like
disposeNative. As a rule, disposeNative is dispatched to the queue with
the least priority among the queues that other native members of the
same class dispatch to (i.e. "gecko_priority" if all other native
members dispatch to "gecko_priority", or "gecko" if any native members
dispatch to "gecko").
Bug 1344892 - 3. Update auto-generated bindings; r=me
This change automatically evicts content scripts 5 minutes after their last
use, and flushes the entire cache whenever a memory-pressure event is
received.
In the case of memory-pressure events other than heap-minimize, we only evict
scripts that have been in the cache for longer than 3 seconds (which is a
fairly arbitrary number) in order to prevent pre-loads from being evicted and
then immediately re-loaded.
MozReview-Commit-ID: LCXkI9qVMxS
--HG--
extra : rebase_source : b81ed3b9962346154fa18eaee58a7411244a1936
This uses the http-on-opening-request observer that's dispatched in the child
process to begin preloading matching content scripts as early in the load
cycle as possible. Ideally we would use the network predictor for this, but
most of its prediction work happens in the parent process, and there are no
simple ways for us to hook into it.
This currently does not do any pre-loading in the parent process, mainly
because there isn't a good way to distinguish top-level document loads that
are happening directly in the parent versus those that are being proxied from
the child.
MozReview-Commit-ID: dIQW68HtxZ
--HG--
extra : rebase_source : b36f6c8516d0550a0d5bb0df895ce6db76ab3538
In order to asynchronously load content scripts that need to run very early in
the page load cycle, before any ordinary page scripts, we need to be able to
block parsing from the document-element-inserted listener. Since the script
loader operates by returning promises, blocking on promise resolution is the
simplest way to achieve this.
MozReview-Commit-ID: CTWlyrP6dqG
--HG--
extra : rebase_source : 28ce713a6450c223f9b2089e6c6e8c78284ef8af
In order to asynchronously load content scripts that need to run very early in
the page load cycle, we need to be able to block further parsing from the
document-element-inserted observer, before any page scripts are loaded.
Interrupting the flush loop after the document element is inserted allows
the observers to run, and temporarily block further parsing if necessary.
MozReview-Commit-ID: A6D2T52Mlx4
--HG--
extra : rebase_source : 86f303a0bf298ac32b934290a7f960a2e1bac581
In order to support asynchronous loading of extension content scripts, we need
to be able to exit the HTML parser flush loop immediately after inserting the
document element. Normally this doesn't cause problems, but when we enter edit
mode with an empty element selected, the editor inserts a <br> node, and a
<br> node at the start of the <html> element causes issues.
These changes solve that issue by putting off entering editor mode until we
begin laying out the document.
MozReview-Commit-ID: H2ksNz0jRxs
--HG--
extra : rebase_source : 26e0d254744363f5bd60f3b4f4df7b51c3dc446f
We're now asserting that we never check these before the END_ALL_PREFS phase,
which means they don't need to be sent to the content process synchronously.
MozReview-Commit-ID: 4BGbvVCjDWz
This ensures that we don't read incorrect values out of the gPropertyEnabled
array simply because we haven't gotten preference values from the parent process
yet.
MozReview-Commit-ID: 59AgN3ecXQl
