The text track list should not exceed the size of the video controls. Because it is positioned
absolutely, and because the height of the video is not known in the CSS, the only way to
ensure the list's height does not exceed the video's height is to set a 'top' value as well as
a 'bottom' one.
Unfortunately, that then means that if the list is quite small and the video quite tall, the
popup becomes way too large.
To avoid this, I've added another level of nesting, and used flexbox to align the actual list
to the bottom of the container for the list.
Differential Revision: https://phabricator.services.mozilla.com/D62452
--HG--
extra : moz-landing-system : lando
The text track list should not exceed the size of the video controls. Because it is positioned
absolutely, and because the height of the video is not known in the CSS, the only way to
ensure the list's height does not exceed the video's height is to set a 'top' value as well as
a 'bottom' one.
Unfortunately, that then means that if the list is quite small and the video quite tall, the
popup becomes way too large.
To avoid this, I've added another level of nesting, and used flexbox to align the actual list
to the bottom of the container for the list.
Differential Revision: https://phabricator.services.mozilla.com/D62452
--HG--
extra : moz-landing-system : lando
This patch also exposes the desktop environment and window protocol on
the gfx blocklist, allowing us more control over feature deployment.
This will help with the slow rollout of WebRender to release channels.
Differential Revision: https://phabricator.services.mozilla.com/D56563
--HG--
extra : moz-landing-system : lando
This patch also exposes the desktop environment and window protocol on
the gfx blocklist, allowing us more control over feature deployment.
This will help with the slow rollout of WebRender to release channels.
Differential Revision: https://phabricator.services.mozilla.com/D56563
--HG--
extra : moz-landing-system : lando
The getDefaultFileName helper function does its own filename parsing using header info
it has previously 'manually' retrieved, so it needs to manually unescape its input.
Meanwhile, NS_GetFilenameFromDisposition is used by webbrowserpersist and for
the title of documents, and so updating that helps ensure better UI as well as
correct filename suggestions when saving from the context menu.
Differential Revision: https://phabricator.services.mozilla.com/D61734
--HG--
rename : accessible/tests/mochitest/moz.png => uriloader/exthandler/tests/mochitest/file_with@@funny_name.png
rename : toolkit/components/mediasniffer/test/unit/data/file.webm => uriloader/exthandler/tests/mochitest/file_with[funny_name.webm
extra : moz-landing-system : lando
The code was using activeElement which is not safe inside shadow DOM as it is
retargeted.
Differential Revision: https://phabricator.services.mozilla.com/D61331
--HG--
extra : moz-landing-system : lando
Changes:
Migrate over the platform of `mochitest-chrome` to ubuntu1804:
Mark as expected failure one test, and expand the disable annotation of another test to include all platform variants of linux.
Resulting runs have some intermittent failures but nothing significant.
Differential Revision: https://phabricator.services.mozilla.com/D60612
--HG--
extra : moz-landing-system : lando
* renames aboutNetworking.xhtml to aboutNetworking.html
* fixes markup to be valid html
* fixes missing instructions link in about:networking#logging
Differential Revision: https://phabricator.services.mozilla.com/D60814
--HG--
rename : toolkit/content/aboutNetworking.xhtml => toolkit/content/aboutNetworking.html
extra : moz-landing-system : lando
MozTrees persist column ordering using the XUL persist="ordinal" attribute. This patch synchronizes MozTree with that old mechanism to restore the ability to save and restore column ordering. Because the persist data will be stored in the same place as before, this should prevent people from losing their column ordering data without requiring data migration.
Differential Revision: https://phabricator.services.mozilla.com/D59763
--HG--
extra : rebase_source : 0474619cb817263d7a56b970c44cf8987d719355
extra : histedit_source : d8ed787170f5dd3ac6e19bf318e1a69c9ad0eac5
This removes nsTreeColumns::RestoreNaturalOrder, which requires the ordinal attribute to function. It only has one consumer: toolkit/content/widgets/tree.js. The call is removed from that consumer in this patch. This will break column ordering in MozTree's, which is fixed by a later changeset in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D59761
--HG--
extra : rebase_source : 88c0b1dda44dc64eedbb73f7902e6cc61faeee1b
This patch was started by Alex Vamvounis <a.vamvounis@gmail.com> and finished by
Mike Conley <mconley@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D53075
--HG--
extra : moz-landing-system : lando
This both allows proper CSS sizing (it respects max-width), and allows for hidden overflow for long badges.
Using xul:label with textContent fixes the former but doesn't support the latter, so an html:label is used instead.
Differential Revision: https://phabricator.services.mozilla.com/D57652
--HG--
extra : moz-landing-system : lando
ContentBlockingEvents is now accessed via WindowGlobalActor::ContentBlockingEvents.
Updating and storing contentBlockingEvent in RemoteSecurityUI are no longer needed.
Depends on D55622
Differential Revision: https://phabricator.services.mozilla.com/D55623
--HG--
extra : moz-landing-system : lando
ContentBlockingEvent in RemoteSecurityUI is updated after receiving a notification from a child process.
Since contentBlockingEvent will be removed from the child, this patch removes the use of
contentBlockingEvent in RemoteSecurityUI and uses the API defined in WindowGlobalActor.
Depends on D55621
Differential Revision: https://phabricator.services.mozilla.com/D55622
--HG--
extra : moz-landing-system : lando
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
This patch adds a lot of `beforeinput` event tests into existing mochitests
which test `input` events. But this does not add tests of canceling
`beforeinput` event because it requires really complicated path until
implementing `beforeinput` actually.
Note that `beforeinput` event is not fired with `Document.execCommand()`.
Therefore, this patch does not add WPT for testing `beforeinput` event.
And unfortunately, WPT cannot test most cases of the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D58123
--HG--
extra : moz-landing-system : lando
`AutoEditActionDataSetter` is created in the stack when editor's public method
is called and that guarantees lifetime of global objects in editor such as
editor itself, selection controller, etc.
The dispatcher of `beforeinput` event returns `NS_ERROR_EDITOR_ACTION_CANCELED`
if an event is actually dispatched but canceled. The reason why it's an error
is, editor code must stop handling anything when any methods return error.
So, returning an error code is reasonable in editor module. But when it's
filtered by `EditorBase::ToGenericNSResult()` at return statement of public
methods, it's converted to `NS_SUCCESS_DOM_NO_OPERATION`. This avoids throwing
new exception, but editor class users in C++ can distinguish whether each edit
action is canceled or handled. The reason why we should not throw new
exception from XPCOM API is, without taking care of each caller may break some
our UI (especially for avoiding to break comm-central). Therefore, this patch
does not make XPCOM methods return error code when `beforeinput` event is
canceled.
In most cases, immediately after creating `AutoEditActionDataSetter` is good
timing to dispatch `beforeinput` event since editor has not touched the DOM
yet. If `beforeinput` requires `data` or `dataTransfer`, methods need to
dispatch `beforeinput` event after that. Alhtough this is not a good thing
from point of view of consistency of the code. However, I have no better
idea.
Note 1: Our implementation does NOT conform to the spec about event order
between `keypress` and `beforeinput` (dispatching `beforeinput` event after
`keypress` event). However, we follow all other browsers' behavior so that it
must be safe and the spec should be updated for backward compatibility.
Spec issue: https://github.com/w3c/uievents/issues/220
Note 2: Our implementation does NOT conform to the spec about event order
between `compositionupdate` and `beforeinput`. Our behavior is same as
Safari, but different from Chrome. This might cause web-compat issues.
However, our behavior does make sense from point of view of consistency of
event spec. Additionally, at both `compositionupdate` and `beforeinput`,
composition string in editor has not been modified yet. Therefore, this
may not cause web-compat issues (and I hope so).
Spec issue: https://github.com/w3c/input-events/issues/49
Note that this patch makes editor detect bugs that `beforeinput` event hasn't
been handled yet when it dispatches `input` event or modifying `data` and
`dataTransfer` value are modified after dispatching `beforeinput` event with
`MOZ_ASSERT`s.
Differential Revision: https://phabricator.services.mozilla.com/D58127
--HG--
extra : moz-landing-system : lando
This patch adds a lot of `beforeinput` event tests into existing mochitests
which test `input` events. But this does not add tests of canceling
`beforeinput` event because it requires really complicated path until
implementing `beforeinput` actually.
Note that `beforeinput` event is not fired with `Document.execCommand()`.
Therefore, this patch does not add WPT for testing `beforeinput` event.
And unfortunately, WPT cannot test most cases of the new tests.
Differential Revision: https://phabricator.services.mozilla.com/D58123
--HG--
extra : moz-landing-system : lando
This is basically the same technique as `descriptionHeightWorkaround` in the
PanelMultiView implementation (from bug 1009116).
Differential Revision: https://phabricator.services.mozilla.com/D58948
--HG--
extra : moz-landing-system : lando
<xul:description> doesn't respect `display` and effectively behaves like
`display: flow-root` unless it has the `value` attribute.
<xul:label> and <xul:button> are expected to be inline level when in HTML
blocks.
The former fixes the about dialog. The later fixes the session restore page,
which in today's nightly shows the two buttons in different lines.
I could try to write more targeted fixes if you want, and probably switching to
html layout while at it.
<label> can be display: inline, at least in the about dialog. And the
<xul:button> in the restore session page can be <html:buttons> (inline-blocks).
But then again the involved elements always create specific layout boxes
disregarding display, so this patch does effectively the same.
Differential Revision: https://phabricator.services.mozilla.com/D59093
--HG--
extra : moz-landing-system : lando
If we are setting up a new permission prompt from iframe navigation, the popup
notification may reuse "checked" value from previous notification, even if the
checkbox is hidden. We should clear checkbox.checked (set to false) if the
checkbox is hidden
Differential Revision: https://phabricator.services.mozilla.com/D58516
--HG--
extra : moz-landing-system : lando
It was being set to null before we tried to remove it, which left a dead
controller registered and consuming commands after a frameloader rebuild.
Differential Revision: https://phabricator.services.mozilla.com/D57556
--HG--
extra : moz-landing-system : lando
After bug 1598841, they don't inherit `direction` from the root, so we need to
explicitly style the default toltip.
Differential Revision: https://phabricator.services.mozilla.com/D58367
--HG--
extra : moz-landing-system : lando
We remove `file_blockMedia_shouldPlay.html` and `file_blockMedia_shouldNotPlay.html` and move those operation on test directly, and do those operations after media fully loading.
And seperate two different test cases to two testing tasks.
Differential Revision: https://phabricator.services.mozilla.com/D58275
--HG--
extra : moz-landing-system : lando
`synthesizePlainDragAndDrop()` synthesizes drag events with `DataTransfer`
object which is set to `DragEvent.dataTransfer` of `dragstart` after starting
drag session explicitly. However, this causes
`EventStateManager::DoDefaltDragStart()` does not initialize `nsIDragService`
instance. Therefore, synthesized drag events cannot work with editor because
`DragEvent::GetMozSourceNode()` returns `nullptr` due to
`nsIDragSession::GetSourceNode()` returning `nullptr`.
On the other hand, synthesized drag events cannot use
`nsIDragService::InvodeDragSession()` normally because of hitting an assertion.
https://searchfox.org/mozilla-central/rev/690e903ef689a4eca335b96bd903580394864a1c/widget/nsBaseDragService.cpp#230-233
This patch does:
- mark drag events caused by synthesized mouse events as "synthesized for tests"
- make `synthesizePlainDragAndDrop()` stop using
`nsIDragService.startDragSession()`
- make `nsBaseDragService` initialize and start session even for synthesized
`dragstart` event
- make `synthesizePlainDragAndDrop()` stop synthesizing drag events with
`DataTransfer` object since it's normal behavior and it'll be initialized
with `nsIDragService::GetDataTransfer()`
- make `nsBaseDragService` store `effectAllowed` for the session only when
it's synthesized session because it's required at initializing synthesized
default `dropEffect` value of `dragenter`, `dragover`, `dragexit` and `drop`
events' `dataTransfer`
- make all tests which use `nsIDragService.startDragSession()` use new
API, `nsIDragService.startDragSessionForTests()` to initialize session's
`effectAllowed` value
- make `EventStateManager::PostHandleEvent()` set drag end point of the test
session to `eDrop` event's screen point
- make `synthesizePlainDragAndDrop()` set drag end point of the session if
it does not synthesize `drop` event because following `endDragSession()`
use it at dispatching `dragend` event on the source element
Additionally, this adds `dumpFunc` new param to `synthesizePlainDragAndDrop()`
because it's really useful to investigate the reason why requesting DnD isn't
performed as expected.
Differential Revision: https://phabricator.services.mozilla.com/D57425
--HG--
extra : moz-landing-system : lando
Update the GMP fallback downloader for Widevine to reference the 4.10.1582.2
CDM. This keeps the fallback URLs in step with Balrog.
Add an alias for `Linux_x86_64-gcc3-asan` to `Linux_x86_64-gcc3`. This alias
exists in the Balrog rules already. This covers the case where the fallback is
needed for such asan builds.
Differential Revision: https://phabricator.services.mozilla.com/D57725
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Most of these fixes involve fixing test XUL to not use <dialog> as a top level element or replacing calls to document.documentElement that expect it to return the dialog, now that the dialog is not the top level element anymore.
Differential Revision: https://phabricator.services.mozilla.com/D53722
--HG--
extra : moz-landing-system : lando
This patch also includes necessary JS changes to support this. Most commonly, the dialog was accessed with document.documentElement, which needed to be changed now that the dialog is not the top level element.
Differential Revision: https://phabricator.services.mozilla.com/D52411
--HG--
extra : moz-landing-system : lando
We need to ensure the rules that override all properties for scrollbar
part elements only apply to those that are NAC (and so will be eligible
for NAC style sharing). We have some uses of non-NAC <scrollbar>
elements that should continue to inherit properties from their parents.
To avoid any changes in rule matching order that come with changing specificity,
we add a new :-moz-native-anonymous-no-specificity pseudo-class.
While we're here, we note :-moz-native-anonymous-no-specificity (and the
regular :-moz-native-anonymous pseudo-class) as not needing style
sharing cache revalidation, as we never share NAC styles.
Differential Revision: https://phabricator.services.mozilla.com/D56154
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
Also increase the min-width for password generation popups so at least en-US doesn't wrap.
Depends on D55742
Differential Revision: https://phabricator.services.mozilla.com/D55743
--HG--
extra : moz-landing-system : lando
Some of these were obvious typos. Others probably reflect once-correct components
that have been combined, split, or otherwise obsoleted; for these I've tried to
use the component associated with the bugs for recent changes to the affected files.
Differential Revision: https://phabricator.services.mozilla.com/D55756
--HG--
extra : moz-landing-system : lando
egao
Brendan Dahl
Henri Sivonen
Gijs Kruitbosch
Dorel Luca
Tim Nguyen
Neil Deakin
Chris H-C
Andrew Osmond
Razvan Maries
Kris Maglione
Mihai Alexandru Michis
Emilio Cobos Álvarez
Zibi Braniecki
Rob Wu
Cosmin Sabou
Matthew Gregan
Jan Varga
Dão Gottwald
Valentin Gosu
Kirk Steuber
Mike Conley
Sylvestre Ledru
Mark Banner
Narcis Beleuzu
Brian Grinstead
Dimi Lee
Magnus Melin
Masayuki Nakano
Alexander Surkov
Brindusan Cristian
shindli
Tom Schuster
Thomas Nguyen
Greg V
Brian Hackett
Jason Laster
alwu
Ciure Andrei
Bryce Van Dyk
Tyler
Bogdan Tara
Emma Malysz
Bryan Kok
Gurzau Raul
Alex Henrie
Daniel Varga
Cameron McCormack
Noemi Erli
Masatoshi Kimura
Julian Descottes
Matthew Noorenberghe
Geoff Brown
Wendy Wigg