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
Mike Conley
Dão Gottwald
Sylvestre Ledru
Mark Banner
Mihai Alexandru Michis
Neil Deakin
Zibi Braniecki
Narcis Beleuzu
Brian Grinstead
Dimi Lee
Magnus Melin
Masayuki Nakano
Razvan Maries
Gijs Kruitbosch
Alexander Surkov
Emilio Cobos Álvarez
Kirk Steuber
Brindusan Cristian
shindli
Tom Schuster
Thomas Nguyen
Greg V
Kris Maglione
Brian Hackett
Jason Laster
alwu
Ciure Andrei