By returning the shadow root as the parentNode of some elements, the breadcrumbs could no longer
display the chain of elements correctly, because shadowRoot.parentNode is null.
This changeset:
- returns the host actor ID as part of the shadowRoot form
- adds a parentOrHost convenience method on the node form
- uses said method in selection and breadcrumbs when walking up the ancestor chain
I don't think we should unconditionally return the host element as the parentNode of the
shadow root, because that is too disconnected from the reality.
MozReview-Commit-ID: JLeDb4VuT1q
--HG--
extra : rebase_source : 33f1f6e8dd221754a4a8fb32f954e5d277110917
Both reason and isSlotted arguments of setNodeFront are optional, switching to an
object argument avoids weird calls such as setNodeFront(front, null, true) in favor
of a more explicit setNodeFront(front, { isSlotted: true });
MozReview-Commit-ID: A6nziH3QQYe
--HG--
extra : rebase_source : e5bde9e74369e1b0fb2e1d1a0a2b31a0131caacd
The ellipsis character displayed by devtools is now relying on a localized string
in devtools/client/shared.properties instead of a complex preference.
The lazy loading of the ellipsis string has been removed, the ellipsis is retrieved
once when the client/shared/l10n.js file is loaded.
The ellipsis property on the LocalizationHelper instances has been removed in favor
of an ELLIPSIS export on the l10n.js module.
All the previous callers using either LocalizationHelper::ellipsis or retrieving the
intl.ellipsis preference have been migrated to rely on the ELLIPSIS export of l10n.js
MozReview-Commit-ID: 4JG0qbJGCw9
--HG--
extra : rebase_source : b513f69a00335c63c46e085b0101ca4cf884fb08
extra : source : 9cea22b583c7d615be644dd50161902c35f2f1b7
The intermittency is caused by a race condition. When delete is clicked in the
context menu, markupview changes the selection and sends the removeNode request
to the server. The selection change triggers the usual inspector update process
in the client. At the same time, the server removes the node and queues the
mutation triggered by the removal. And here lies the issue.
If the inspector components finish updating BEFORE the removal mutation is
received from the server, the test continues before the breadcrumbs learn
about the deletion and the test fails. If the update is still pending when
the mutation is received, the breadcrumbs have time to update before the
test continues to make assertions about the breadcrumb contents.
The fix here is to make the test to ensure that the breadcrumbs have seen the
deletion before it continues. To enable that, the breadcrumbs need to tell
the world that it has been updated even if the breadcrumbs were just trimmed
and a non-element node was selected that does not trigger the full update
process (early return in the code).
As the inspector update process has been collecting cruft for years and tests
make a lot of assumptions about the emitted events, it's not safe to trigger a
new inspector update in this special case. Therefore, only the
breadcrumbs-updated event is emitted in this special case and the test waits
for that if the deleted node is still present in the breadcrumbs.
MozReview-Commit-ID: AjC6k6SzLCu
--HG--
extra : rebase_source : 64260d447973c352a5df064bc7f5630b6b92fe81
Using mouseleave in chrome code generates a warning in docshell about
performance which notes mouseout should be used instead. This patch replaces
usage of mouseleave with mouseout across the devtools codebase.
This patch converts the inspector's context menu implementation away from
directly using XUL menus, and updates a number of tests to match.
MozReview-Commit-ID: L8aL23BUmXS
Existing keyboard shortcuts have been reimplemented using the new shortcut-key
api.
A keypress handler was removed on the breadcrumbs buttons, it had no use
since a focused button is always selected.
MozReview-Commit-ID: JTSRxwQGSlh
--HG--
extra : rebase_source : 4466162a2cf2bd77cb50ee77ea5843c973ceb5b2
Add a displayName property on the NodeActor, which compute from Element.prefix + Element.localName.
The computation is made by a getNodeDisplayName function which can be imported wherever needed.
Edit some tests to ensure we correctly display node names.
MozReview-Commit-ID: 6z0G3ynbMoU
--HG--
extra : transplant_source : %E0%AFM%88D%BC%AD%08%1D%A4%FB%F2%5D%9E%D3%90%DE%94%EC%CD
The breadcrumbs widget used to have a feature where it would show the first
child of the current selection even the DOM tree hadn't been expanded that
far yet.
This was to allow keyboard navigating the DOM through the breadcrumbs.
The breadcrumbs is a very rarely used widget and this code was unnecessarily
making things complex.
It was decided that this feature would be removed.
Instead, the breadcrumbs now act as simple linear elements in a toolbar and
you can keyboard navigate them with LEFT/RIGHT only. TAB/shift-TAB simply go
in/out of the breadcrumbs widget.
MozReview-Commit-ID: BmcaLnVBOBn
--HG--
extra : rebase_source : 1673a6c9da02cf8b3b542e4ce905ccb239250aa7
