This patch renames HTMLEditor::DeleteRow() to
HTMLEditor::DeleteTableRowWithTransaction() and cleans up its implementation.
Differential Revision: https://phabricator.services.mozilla.com/D5931
--HG--
extra : moz-landing-system : lando
nsITableEditor::DeleteTableRow() is an XPCOM method but there are some internal
users. So, it should be implemented as non-virtual protected method and
internal users should use it instead.
This also renames (and reimplement) HTMLEditor::DeleteTable2() since it's
really bad name and the code dispatches unnecessary "selectionchange" events.
Differential Revision: https://phabricator.services.mozilla.com/D5930
--HG--
extra : moz-landing-system : lando
This patch changes a bit in HTMLEditor::DeleteTableRow() because calling
DeleteTable2() without those helper classes hits MOZ_ASSERT().
Differential Revision: https://phabricator.services.mozilla.com/D5929
--HG--
extra : moz-landing-system : lando
Remove Unused aParentContext Parameter in ServoStyleSet::ResolveStyleFor Function
Differential Revision: https://phabricator.services.mozilla.com/D5979
--HG--
extra : moz-landing-system : lando
This removes subscribe UI and functionality from the main browser window,
the page info window, and from feed previews. It may leave some stray strings
in subscribe.properties/dtd, which will be removed in bug 1477669 when the
preview code goes away completely.
Differential Revision: https://phabricator.services.mozilla.com/D5982
--HG--
extra : moz-landing-system : lando
This reverts the changes in bug 1360308, bug 1390143 and bug 1469603. Minidump
generation will now only happen on the main process' main thread which might
lead to hangs but is known to be fairly robust. Asynchronous generation proved
too brittle and enormously increased the complexity of this already
hard-to-read code.
Differential Revision: https://phabricator.services.mozilla.com/D5147
--HG--
extra : moz-landing-system : lando
Prior bug 1416085, reads were clamped to the content's duration (if known). It appears that the new code relied on MediaCacheReadBlockFromCache to properly account for the end of content.
However, this was not the case, the MediaCache always reads (and write) one full block at a time regardles of the size requested (a block is 32768 bytes).
Rather than clamping in the Read() method as it used to be, we clamp in ReadBlockFromCache as such safety will benefit other callers that would have otherwise also returned garbage reads.
Differential Revision: https://phabricator.services.mozilla.com/D5964
--HG--
extra : moz-landing-system : lando
Always new reasons to remove the first-line frame and this reparenting stuff...
I hope I can get to it.
Differential Revision: https://phabricator.services.mozilla.com/D5075
--HG--
extra : moz-landing-system : lando
If we're trying to detach and reattach the same compositor object for
whatever reason, we should skip it so we don't inadvertently end up not
attaching the object at all.
Differential Revision: https://phabricator.services.mozilla.com/D5608
--HG--
extra : moz-landing-system : lando
Here we are simulating a user typing a few letters in
the console input, when the console output has 500 messages.
We wait between each 'keystroke' in order to have a
realistic measure. Also, we are typing a string that is
triggering the popup as it also impacts typing performance.
Differential Revision: https://phabricator.services.mozilla.com/D4658
--HG--
extra : moz-landing-system : lando
When the user is editing the text in the URL bar (typing, backspace, etc.), the first suggestion is always selected.
Because accessibility clients require autocomplete items to be "focused", the code needs to differentiate between explicit selection (e.g. via down/up arrow) and auto selection (e.g. when typing).
Otherwise, the focus continually moves away from the text box while the user is typing, as was previously occurring.
This makes it very difficult for the user to edit text, particularly backspace/delete.
There was a previous attempt to handle this, but it was somewhat fragile and broke completely some time ago.
Now, rather than trying to handle this based on autocomplete events, it is handled in the input and key press events.
For input events, accessibility focus is forced back to the text box and further accessibility focus events are suppressed.
For down arrow, up arrow, etc. key presses, accessibility focus events for suggestions are enabled.
This makes it easier to understand and predict the user experience, rather than relying on underlying autocomplete implementation details.
This is tested using an accessibility browser test, which makes it easier to make assertions about accessibility focus.
This also means that if the underlying implementation details change (e.g. HTML + aria-activedescendant instead of XUL + DOMMenuItemActive events), this test should still be valid and allow us to catch regressions.
Differential Revision: https://phabricator.services.mozilla.com/D5987
--HG--
extra : moz-landing-system : lando
A previous patch in this bug made the incorrect assumption that we had disabled
the family safety root detection/importing feature by default. In reality, we
enabled it by default in bug 1282871.
In bug 1487258 we moved enterprise root loading to a background thread so as to
not block the main thread. This patch does the same with the family safety
feature.
Differential Revision: https://phabricator.services.mozilla.com/D5484
--HG--
extra : moz-landing-system : lando
Julian Descottes
Masayuki Nakano
Nazım Can Altınova
Jean-Luc Bonnafoux
Lina Cambridge
Gijs Kruitbosch
Daisuke Akatsuka
Arshad Kazmi
Ciure Andrei
Ehsan Akhgari
Bogdan Tara
Coroiu Cristina
Gabriele Svelto
Jean-Yves Avenard
Dorel Luca
Logan F Smyth
Robert Helmer
Francesco Lodolo (:flod)
Emilio Cobos Álvarez
Jim Chen
Alessio Placitelli
Nicolas Chevobbe
Chris Manchester
James Teh
Ryan VanderMeulen
Dana Keeler
Andrew Swan
Jed Davis