Note that the to_json method prefers the taskgraph's dependencies information
(edges) to that from the task.dependencies entries. At a few points in
task-graph generation, these values differ, although that is expected (for
example, the full task set contains no edges, but that information is still in
task.dependencies). Unifying that representation leads to some difficulty with
task transforms that reach into the dependency tree (beetmover), so the
different representations are left as-is.
MozReview-Commit-ID: GeW8HNwFA9Z
--HG--
extra : rebase_source : 549773e05e18371a399612d9bceccffc29be8cf2
Instead of using a class's static method, use a simple function, specified by
the `loader` key.
MozReview-Commit-ID: IeOl9qiSCXf
--HG--
extra : rebase_source : 72e0a9dd8385b250a46c9f4adf8a8a0e5b01c156
We want to give a chance to the embedder to handle a link itself.
Is it a problem that this will add a round trip to the main thread every time `load_url` is called?
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#15655
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because I'm not sure how to test that
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 808ffffd1e8dab9ca6340a981b797434b34e2e36
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 667e921e89833af26350326ab50d27517fc29cb3
This commit updates part of the logic changed in Bug 1333714 (e3a0d990896d)
The hide method of the auto refresh highlighters were modified to allow
hide() to be called as long as the highlighter env window was still valid.
This could lead to calling hide on highlighters where show() had not been
previously called, slowing down closing the inspector for no reason.
This changes the hide() method to also bail out in case this.currentNode
is not truthy, which means show() was not called previously.
MozReview-Commit-ID: 4EOgjD6W2QB
--HG--
extra : rebase_source : acfcb14dc2e4098b035de23b1b09212e418cf2de
It should be possible to set a window's position to a pair of negative
coordinates, since the user may move the window off-screen. The window
may also be situated off-screen by default: for example a maximised
window on Windows will report window.screenX to be -8px.
Relevant change to the specification:
https://github.com/w3c/webdriver/pull/805
MozReview-Commit-ID: FdReDi8pLL0
--HG--
extra : rebase_source : 08bb52e10ffec16a1414d336653990c8d9d7e1a8
When we load about:blank in a remote tab, it will have
LOAD_FLAGS_DISALLOW_INHERIT_PRINCIPAL flag set, which will make
NullPrinicipal as its document principal. So we add
NULL_PRINCIPAL_FIRST_PARTY_DOMAIN as its firstPartyDomain.
So when we load data:, or javascript: URI in a remote tab, it will inherit the
principal from about:blank, hence also inherit the origin attributes.
There are also some about: pages will use codebase principal, so we also
set ABOUT_URI_FIRST_PARTY_DOMAIN as firstPartyDomain on their
principals.
Also fixes a slight issue in firebug theme that made the text slide of
1 px down when selecting a tab.
MozReview-Commit-ID: KNm9Xf21p2D
--HG--
extra : rebase_source : 98728735c36446a116a5a2cb2306f39e5a72f21c
extra : source : c342d199c1397fbb66c3c6f70cfe42b5d3817cc2
- remove text-overflow: ellipsis to maximize readable text
- add media query to hide toolbar icons when viewport width < 700px
MozReview-Commit-ID: 4HBFciWSuie
--HG--
extra : rebase_source : 64fde49c46c93f963ba073832d9f54902b078809
extra : source : d86ba00ee51ec5b1571009370a93f7ded5baa65b
The pref has never been enabled, so this is quite surprising!
It is currently possible (and has been for quite a while) to discard animated images. All we need is the follow sequence of events.
1. Decode an animated image.
2. Move the animated image out of view (so it is not painted).
3. Call canvas.drawImage on the animated image (or anything else that asks for a first frame only decode). This creates a static entry in the surface cache for this first frame in addition to the animated entry. Because it is a static request we will also start a first frame decode. RasterImage::Decode calls SurfaceCache::UnlockEntries
https://dxr.mozilla.org/mozilla-central/rev/4ceb9062ea8f4113bfd1b3536ace4a840a72faa7/image/RasterImage.cpp#1166
and bam, the animated frames are now unlocked (even though the RasterImage, and it's entry in the surface cache is still locked).
4. Switch tabs, open about:memory and minimize memory to actual throw away the animated frames.
5. Switch back to the image tab, scroll the image back into view, it will not animate, it will just show the last composited frame forever.
This patch does the following.
- Introduces NotifyObservers() for the simple notification cases in
platform.cpp.
- Removes profiler_lock() and profiler_unlock() because they do notifications
that the profiler add-on no longer listens for.
--HG--
extra : rebase_source : 77a1868ba494dea314702bbdf9478a1da36c9efb
Calling NotifyObserver() with gPSMutex locked is a bad idea; arbitrary code can
run in observers, which can easily include code that calls other profiler
functions that themselves lock gPSMutex, causing deadlock. This has been seen
in practise with locked_profiler_stop().
This patch moves all but one of the NotifyObserver() calls in platform.cpp to
after the sections where gPSMutex is locked. The remaining call (for the
"profiler-subprocess") is harmless, because it just calls a simple callback
implemented within platform.cpp, and hard to move.
In the future we plan to allow profiler_start() and profiler_stop() to be
called from different threads. When that happens, it will be possible for the
"profiler-start" and "profiler-stop" notifications to arrive out of order.
Unfortunately this seems difficult to avoid. (Well, recursive mutexes would
make this problem much easier, but we don't have those...)
--HG--
extra : rebase_source : 78455c4b2d93a0d4110cdd401d6b542b641dd217
