This moves the eyedropper button from the toolbar into the inspector,
therefore the old eyedropper command isn't needed anymore,
or at least not as it was.
The button in the inspector simply uses the pickColorFromPage inspector
actor method.
And to preserve a eyedropper gcli command, a new simpler one was added.
MozReview-Commit-ID: B1yr1EqLFBD
--HG--
extra : rebase_source : 47c2effe193f4d1a64a8d16ea3609ff5ae1f793b
The inspector actor now has a new method that can be used to pick a
color from the page. This method just instantiates the eye-dropper
highlighter and shows it on the page.
The method doesn't return the color because this requires user interaction.
Instead, it returns immediately and an event is sent later, when the user
has selected a color or escaped.
MozReview-Commit-ID: cjadLyNXQd
--HG--
extra : rebase_source : 392a3cbfce7b81518cd7e4c90a44bae17d96e8de
This is mostly porting code from the XUL eye-dropper over to a new
highlighter file.
While I have tested this locally, this highlighter isn't yet used
in devtools.
This will come in later patches.
MozReview-Commit-ID: IF0puLu5Yc7
--HG--
rename : devtools/client/shared/css-color-db.js => devtools/shared/css-color-db.js
rename : devtools/client/shared/css-color.js => devtools/shared/css-color.js
extra : rebase_source : 72431a9148d1c688987a5693a619769837c774c7
::before and ::after pseudo-elements are visible in the markup-view today
but if, for some reason, they aren't generated, we still want to know that
the CSS rule exists.
This may happen if you use display:none on the pseudo-element CSS rule itself.
When that happens, the pseudo-element won't be generated and therefore there
will be no possibility to see the rule in the rule-view (you'd have to go to
the style-editor for that).
This change keeps the pseudo-elements in the markup-view, but also adds the
corresponding CSS rules in the rule-view.
MozReview-Commit-ID: tx5IpmtE7b
--HG--
extra : rebase_source : 19979672561e55fc5713900b83dd6d40ac33d2a3
Also contains folded version of the following patches that have to land at the same time with enabling the new implementation (or be backed out at the same time, if it comes to that):
Add Promise checks to test_xrayToJS.xul. r=bholley
Change Promise debugger hook tests to use Promise ctor instead of makeFakePromise. r=shu
Change DOM interface tests to assume Promise is an ES builtin, not a DOM one. r=bz
Remove some PromiseDebugging references. r=bz
Adapt promise rejections test to new xray-unwrapping error. r=bz
Fix expectations in browser_timelineMarkers tests. r=tromey
Also contains folded version of the following patches that have to land at the same time with enabling the new implementation (or be backed out at the same time, if it comes to that):
Add Promise checks to test_xrayToJS.xul. r=bholley
Change Promise debugger hook tests to use Promise ctor instead of makeFakePromise. r=shu
Change DOM interface tests to assume Promise is an ES builtin, not a DOM one. r=bz
Remove some PromiseDebugging references. r=bz
Adapt promise rejections test to new xray-unwrapping error. r=bz
Fix expectations in browser_timelineMarkers tests. r=tromey
Also fix a typo in a comment, "Rules" -> "Rulers"
MozReview-Commit-ID: Gy5k3TR9JDM
--HG--
extra : transplant_source : i%15%1B%A1L%F9%B9%23%CC%F70u%0AT%0C%B4%27m%B2%DF
Also tidy up the HTML a bit by removing errant <img> close tags
MozReview-Commit-ID: 4cmtW1S2BI8
--HG--
extra : transplant_source : %26%E6%FE%BB%FE%2A%CCG%E0%27%3B%3DYK%2BP%E7%9D%C7%C9
Also tidy up the HTML a bit by removing errant <img> close tags
MozReview-Commit-ID: 4cmtW1S2BI8
--HG--
extra : transplant_source : %D3g%9B%CD%16%98E%18%F0%7F%2C%B9%09%19%EB%88L%E4%18%07
There are two leaks addressed in this commit:
1. The thread actor's `_debuggerSourcesSeen` set was never cleared. This set
exists only as a performance optimization to speed up `_addSource` in cases
where we've already added the source. Unfortunately, this set wasn't getting
cleared when we cleared debuggees out and it ended up keeping the
`Debugger.Source`, its referent, and transitively its referent's global alive. I
figured it was simpler to make it a `WeakSet` than to add it as a special case
in `ThreadActor.prototype._clearDebuggees` and manage the lifetimes by hand. I
think this fits well with its intended use as an ephemeral performance
optimization.
2. Due to a logic error, we were not clearing debuggees in the memory actor's
`Debugger` instance on navigations. This isn't really a "proper" leak, in that
if you forced a GC, the old debuggees would go away as `Debugger` holds them
weakly, however if there was no GC between navigations, then you could still see
the old windows (and everything they "retained") as roots in the snapshot. This
issue is straightforward to fix once identified: ensure that `_clearDebuggees`
is actually called on navigation.
Finally, this commit adds a test that we don't leak Window objects when devtools
are open and we keep refreshing a tab. When it fails, it prints out the leaking
window's retaining paths.
