CLOSED TREE
Backed out changeset d24fa1b4553b (bug 1346987)
Backed out changeset 34701b9ed4ba (bug 1346987)
Backed out changeset f24f4fdc5cc8 (bug 1346987)
Fixes#15770
Added a check in border.mako.rs, if `w` and `o` are not none before returning Ok status
---
- [x] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#15770
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they fix the previous errors reported in #15770
Source-Repo: https://github.com/servo/servo
Source-Revision: 94a2262821aae8139ef8cef5a6f2c5e5780aea00
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ce9e7fac6b0c34c2db6cea6c387622af040ee2fe
This patch enables `run-on-projects` to work appropriately for
nightly builds and tests. Initially, we were setting an empty
`run-on-projects` for nightly `build_platform`s, then explicitly
targeting the platforms in nightly-specific `target_task_method`s.
Instead, this patch enables nightlies to `run-on-projects` everywhere,
but governs the use of nightlies by either the `include_nightly`
parameter, or the `--include-nightly` try option. This lets us filter
nightly-related `target_task_method`s against `run-on-projects` without
losing all nightly tasks.
Then, enable spidermonkey tests by removing optimization from beta and
release. This patch also enables everything then disables specific
tasks, rather than disabling everything and enabling specific tasks.
Since we're beginning with a `filter_for_project` call, we should be
able to reduce these if blocks to zero over time, if desired.
MozReview-Commit-ID: A9tolynaChF
--HG--
extra : rebase_source : 3465ee2c714de3e0359f14109096fc94de27aadf
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.
The most important of these is the one in profiler_get_profile_jsobject().
Currently the JS_ParseJSON() call frequently leads to deadlock, due to
profiler_log() being called within it.
--HG--
extra : rebase_source : 7825229da61ad0d567c11bd455a7a9b8f25b5b78
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.
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.
Bug 1344892 - 3. Update auto-generated bindings; r=me
In certain cases, such as dropping a tab's title on the URL bar when Compact
Themes are enabled, the tab dragging UX becomes frozen because it never receives
the expected `dragend` event.
In these situations, the event is lost because the source node we are dragging
becomes detached from the DOM, and so there is no path back to the handlers
waiting for the `dragend` event.
Here we set source node of the drag to the tab element, so that there's always
a stable node in place, and the `dragend` event can be delivered.
MozReview-Commit-ID: JVtEYNA7ImI
--HG--
extra : rebase_source : 867268aa257ebf7c34a09bd3976a4babc564bf89
Because we weren't waiting for the first, "about:blank" page to load, the first
`waitForLoad` could trigger for about:blank. Rather than add an additional
`waitForLoad` it's easier (and probably more future-proof) to just wait for
the right page to load.
MozReview-Commit-ID: DZsMnlgRTa
--HG--
extra : rebase_source : c0fc74368e744fb3e111f310ec98a0b964c23edd