For remote content documents, select dropdowns (for <select size="1">) are rendered in the parent process using a XUL menupopup.
This means that the accessibility code for HTML selects doesn't apply.
In the menupopup, the optgroup is a sibling of its contained options.
For accessibility, we want to preserve the hierarchy such that the options are inside the optgroup.
We do this using aria-owns on the optgroup item.
This required some tweaks to XULMenuitemAccessible, as it couldn't previously handle grouping Accessibles between the menupopup and its items.
Differential Revision: https://phabricator.services.mozilla.com/D43901
--HG--
extra : moz-landing-system : lando
Cloning the original node was needed when we needed the MediaInfo copied over, but
HTMLVideoElement::CloneElementVisually copies it over for us, so we can create a
fresh <video> element. This should also be a much healthier thing to do
security-wise, since we're not cloning strange nodes from the web.
Differential Revision: https://phabricator.services.mozilla.com/D48123
--HG--
extra : moz-landing-system : lando
We weren't handling the case where the toggle has no dimensions, so its X and Y
coordinate would be at 0,0, which would match a click in the top-left corner of
the screen for a video that was fullscreened.
This adds a check that ensures that the toggle has both width and height before
checking whether or not a mouse event occurred within it.
Differential Revision: https://phabricator.services.mozilla.com/D47789
--HG--
extra : moz-landing-system : lando
Originally, we were using the :hover pseudoclass to show the Picture-in-Picture toggle,
and using the DevTools InspectorUtils module to manually apply that :hover pseudoclass
in PictureInPictureToggleChild in the event that the <video> element wasn't able to get
the :hover element "naturally".
Removing this pseudoclass when the mouse leaves the browser window (without first
leaving the toggle) doesn't work, since the mouseout event (which we use to detect
the mouse leaving the window) fires _after_ :hover states would normally be cleared,
so it's too late to "unlock" it.
The solution ended up being replacing the :hover pseudoclass with a .hovering class
that PictureInPictureToggleChild continues to manage on its own.
Differential Revision: https://phabricator.services.mozilla.com/D47677
--HG--
extra : moz-landing-system : lando
For remote content documents, select dropdowns (for <select size="1">) are rendered in the parent process using a XUL menupopup.
This means that the accessibility code for HTML selects doesn't apply.
In the menupopup, the optgroup is a sibling of its contained options.
For accessibility, we want to preserve the hierarchy such that the options are inside the optgroup.
We do this using aria-owns on the optgroup item.
This required some tweaks to XULMenuitemAccessible, as it couldn't previously handle grouping Accessibles between the menupopup and its items.
Differential Revision: https://phabricator.services.mozilla.com/D43901
--HG--
extra : moz-landing-system : lando
Videos can fire their "canplay" events even when they're not part of the DOM. This
means that videos that have already fired that event won't get the
PictureInPictureToggleChild properly attached after being inserted.
The UAWidgetSetupOrChange event, however, is fired for video events once they've
been bound to the DOM, so we can use that instead.
Differential Revision: https://phabricator.services.mozilla.com/D44541
--HG--
extra : moz-landing-system : lando
While working on porting the (audio-playback indicators) bug 1562990 to fission, we saw the potential to delete some methods in nsIDOMWindowUtils because they were not used anymore in our codebase except in a couple of tests files. So now, we should only mute/unmute or change the volume in the parent process. As such, interfaces are added in SpecialPowers to change media muted or volume state from content processes.
Differential Revision: https://phabricator.services.mozilla.com/D41782
--HG--
extra : moz-landing-system : lando
The `xul:menulist` appears a little offset but this is the same as it was prior to the fission patch that completely broke it.
If you have an alternate approach or a way to get the correct position for the `xul:menulist` I am all ears.
Differential Revision: https://phabricator.services.mozilla.com/D40805
--HG--
extra : moz-landing-system : lando
We were using the pagehide event before incorrectly: the pagehide event target
was being inspected to see if it was the top-level frame, and only then, would
we remove the mouse event handlers on the window root.
The problem is that event.target.top on a pagehide event is undefined, since the
event target is a Document.
Further, we probably want to remove any window root event listeners that were
registered for subframes as well. I'm not sure why I decided to try to filter
out subframes, but that definitely can keep windows alive.
So instead, I'm using the "cleanup" method that ActorManagerChild calls if
defined on an ActorChild, which runs when the associated frame unloads. This
way, if a subframe happened to have registered a window root event listener,
it'll get unregistered.
Differential Revision: https://phabricator.services.mozilla.com/D40090
--HG--
extra : moz-landing-system : lando
dennisschagt
James Teh
Mike Conley
shindli
Matt Woodrow
Neil Deakin
Brindusan Cristian
Narcis Beleuzu
Tyler
Coroiu Cristina
Alexander Surkov
Tim Nguyen
monikamaheshwari
Frederik Braun
Noemi Erli
Razvan Maries
arthur.iakab
Emilio Cobos Álvarez
Abdoulaye O. Ly
Michael Ratcliffe
Cosmin Sabou