This prevents us from pushing stuff on the JSContext stack unnecessarily when
we're just cloning, not adopting. It's OK that we're doing it in a narrow scope
that doesn't include our recursion into children, because in practice when
aReparentScope is non-null we came from nsIDocument::AdoptNode which already
does AutoJSContext. So we're not going to continuously push/pop the JSContext
stack in that situation, since something already got pushed on it.
The web platform tests changes are just a cherrypick of
https://github.com/w3c/web-platform-tests/pull/2926 so I don't have to add
failure annotations until the next test uplift.
I've audited our uses of nsIFormControl, and this patch looks to me like it
preserves existing behavior in all but the following cases:
1) nsXBLPrototypeHandler::DispatchXBLCommand, the case of scrolling when space
is pressed while something inside a <label> is focused. We used to not scroll
in this situation; I think this is a bug, so I'm changing that behavior to
scroll instead.
2) In Accessible::RelationByType for the RelationType::DEFAULT_BUTTON case,
when mContent is a <label> we used to return its form's default submit element.
Now we will just return Relation().
We were using nsIDOMWindowUtils to send mousedown and mouseup events
to the <select> input after a selection was made in e10s mode, but
doing so causes focus to be pulled back to the <select> if any input
or change event handlers tried to shift focus. For example, the
reviewer input on Bugzilla was having its focus stolen after setting
the review flag to r?, which was how this bug was discovered.
We're going for mostly-Blink parity here, where it seems (at least on
Windows) a mouseup and click event are dispatched on <select>
elements after the dropdown is closed (either by mouse or keyboard).
We're adding a mousedown just before those, since that seems to make
the most sense.
MozReview-Commit-ID: HAThE6ClBWT
--HG--
extra : rebase_source : 33dea1361ecd114b563c2b972bb6d3811e9d779c
These all definitely use the modern HgVCS because it is explicitly
specified in the configs. So without this change, these configs would
fail since --revision rejects symbolic names.
MozReview-Commit-ID: 2SlVWNVwc08
--HG--
extra : rebase_source : 5e3d0cd075b5a35c4ad0d95b9ec0d6b3715d5080
I'm pretty sure partner repacks are using the modern HgVCS and not
HgToolVCS. So have them use "branch" instead of "revision" for symbolic
revisions.
MozReview-Commit-ID: BuEHGFmK6cK
--HG--
extra : rebase_source : 149d31434a2cf84ff7ade8bff9e7abe4e15e3758
I /think/ hazard builds are currently only performed on TC, which doesn't
use the VCS settings in mozharness. So I don't think this could possibly
break automation.
While I was here, I removed a reference to hgtool since we're no longer
using hgtool in this job.
MozReview-Commit-ID: fQj2MzpGRT
--HG--
extra : rebase_source : f0d0880a50c0597b10c6e97c13f04ae7cf6cc131
The normal MercurialVCS now supports querying pushlog. Use it.
This isn't really relevant to the bug summary and other commits in this
series. But I already wrote this commit and was too lazy to create a
new bug for it.
MozReview-Commit-ID: C97Zgox3xKB
--HG--
extra : rebase_source : e84b6e723e1d481a24a4ba0812735d8b34acd218
We remove the old config settings related to hgtool and switch
the "revision" option to "branch" because it defines a symbolic
revision.
MozReview-Commit-ID: Eq4R5a2tv2V
--HG--
extra : rebase_source : 4d85abbc2db6f499206d741f98c316b9c521b4ee
This adds support for the `-t`/`--talos` option, matching such jobs against
`talos_try_name`. There are no such tasks just yet.
MozReview-Commit-ID: FTEx7Nyyi9Z
--HG--
extra : rebase_source : 64f289ed18a90c4d2c6988935a5865b41367f976
When calling showDefinitionforAttributedString on OSX 10.11, it always return error due to the following exception.
Exception: decodeObjectForKey: class "TitlebarAndBackgroundColor" not loaded or does not exist
So before calling it, we set temporary color value, then restore color after calling it.
MozReview-Commit-ID: 1YeY6X1W6AV
--HG--
extra : rebase_source : 1bfafdb24f7d6df0ad2552b786b8af84b71cc28a