HTMLEditor::DeleteTableCellWithTransaction() does not remove <table> element
even if it becomes empty only when 2 or more cell elements are selected.
Therefore, we should check table size before removing a row and if it's the
last row, the method should remove <table>.
Differential Revision: https://phabricator.services.mozilla.com/D6177
--HG--
extra : moz-landing-system : lando
nsITableEditor::DeleteTableCell() is an XPCOM method but used internally.
So, HTMLEditor should implement it with non-virtual method and use it
internally.
Differential Revision: https://phabricator.services.mozilla.com/D6176
--HG--
extra : moz-landing-system : lando
Should mStreamLength be > 2^32, we could have overflowed leading to false positive test.
Differential Revision: https://phabricator.services.mozilla.com/D6235
--HG--
extra : moz-landing-system : lando
This patch renames HTMLEditor::DeleteColumn() to
HTMLEditor::DeleteTableColumnWithTransaction() and cleans up its implementation.
Differential Revision: https://phabricator.services.mozilla.com/D5934
--HG--
extra : moz-landing-system : lando
nsITableEditor::DeleteTableColumn() is an XPCOM method but used internally.
So, it should be implemented with non-virtual method and internal users
should use it.
Note that this changes only one thing. This moves
|AutoTopLevelEditSubActionNotifier maybeTopLevelEditSubAction(...| from
below DeleteTableElementAndChildrenWithTransaction() to above it.
I.e., DeleteTableElementAndChildrenWithTransaction() works under
EditSubAction::eDeleteNode as the top level sub-action now. This is same
as DeleteSelectedTableRowsWithTransaction(). Therefore, the difference
with it when it removes <table> is now fixed.
Differential Revision: https://phabricator.services.mozilla.com/D5933
--HG--
extra : moz-landing-system : lando
This add automated tests for nsITableEditor.deleteTableColumn().
However, this contains some fixes of existing code since with those bugs,
the test isn't passed even in the simplest case.
Differential Revision: https://phabricator.services.mozilla.com/D5932
--HG--
extra : moz-landing-system : lando
nsITableEditor::DeleteTableCellContents() is an XPCOM method but it's used
internally. So, HTMLEditor should implement it with a non-virtual method
and all internal users should use the non-virtual method instead.
This patch adds HTMLEditor::DeleteTableCellContentsWithTransaction() for that.
Additionally, this patch renames its helper method DeleteCellContents() to
DeleteAllChidlrenWithTransaction() and moves it to HTMLEditor.cpp since it can
handle any element nodes.
Differential Revision: https://phabricator.services.mozilla.com/D6174
--HG--
extra : moz-landing-system : lando
Currently, we have some Gecko specific editing UI:
- Resizers to resize <img>s, <table>s, absolutely positioned elements.
- Inline-table-editing UI to add/remove rows/columns.
- Grabber to move absolutely positioned element.
They are now disabled by default in Nightly and early-Beta. Starting from 64,
this patch makes them disabled by default even on release channel.
Note that the other browsers do not have those UIs and web apps can enable
them with document.execCommand() on Gecko anyway. Those UI usage is enough
low according to the telemetry, but a few users use them aggressively (see
bug 1452538 comment 19).
This is a request from W3C Editing API WG:
https://github.com/w3c/editing/issues/171
Differential Revision: https://phabricator.services.mozilla.com/D6112
--HG--
extra : moz-landing-system : lando
This will allow to check that indeed, when a Notifications related experiment
is enabled, the "Notifications" setting will appear in the menu.
Depends on D5855
Differential Revision: https://phabricator.services.mozilla.com/D6136
--HG--
extra : moz-landing-system : lando
Currently the Notification settings screen lets the user enable/disable
two types of notifications, both depending on Switchboard experiments.
If none of those experiments are available for the user, the entire settings
group will be hidden to avoid any confusion.
Depends on D5854
Differential Revision: https://phabricator.services.mozilla.com/D5855
--HG--
extra : moz-landing-system : lando
The "What's new" notification (bug 1004734) is based on an experiment which
currently is available to noone.
To avoid any confusions the settings entry for it will be hidden if the user
is not in an active "What's new" experiment.
Differential Revision: https://phabricator.services.mozilla.com/D5854
--HG--
extra : moz-landing-system : lando
On Mojave (or later versions) defaultCenter doesn't get the
accessibilityDisplayShouldReduceMotion changes, we need to use
sharedWorkspace.notificationCenter instead.
Note that the reason why we use defaultCenter originally is that using
sharedWorkspace.notificationCenter to post a notification (for mochitest)
crashed on MacOSX 10.10 (on a try).
Differential Revision: https://phabricator.services.mozilla.com/D6201
--HG--
extra : moz-landing-system : lando
This can easily be reproduced if the ancestor being owned has role="presentation", but there are other cases as well.
If we don't prevent this, we end up with a loop.
Differential Revision: https://phabricator.services.mozilla.com/D4051
--HG--
extra : moz-landing-system : lando
This prevents an exception in browser.xhtml when there's no head, since
it's currently sharing the markup with browser.xul.
Differential Revision: https://phabricator.services.mozilla.com/D6194
--HG--
extra : moz-landing-system : lando
The same is done for NEON, and the check folds to nothing when building
when the build target supports SSE2 and runtime detection is not
necessary.
Differential Revision: https://phabricator.services.mozilla.com/D6129
--HG--
extra : moz-landing-system : lando
