The eyedropper code now bails out if the content window is XUL, since
highlighters cant be inserted into non-HTML documents.
And the inspector hides the eyedropper buttons in the toolbar and in the
color-picker if the document isn't HTML.
MozReview-Commit-ID: 7AgRV8Qu9gz
--HG--
extra : rebase_source : 04220a6057df9ced4b49c29e8b46557008e0d738
The eyedropper can be shown in 2 distinct ways:
- the 'eyedropper' gcli command can be called (from the dev toolboar
or from the browser devtools menu),
- or the inspector's 'pickColorFromPage' method can be called (from
the inspector toolbar or from the color-picker in the ruleview).
Before this change, it was possible to show several eyedropper because
these 2 codepaths didn't know about each other.
Now, when executing the gcli command, the inspector's
'cancelPickColorFromPage' method is called to hide it first.
And, when the 'pickColorFromPage' method is called, the 'eyedropper --hide'
gcli command is called too.
This way, there's only one eyedropper shown.
There was also a problem where the gcli command would create a new
eyedropper everytime it was called. This was fixed too, by maintaining a
WeakMap of all eyedroppers opened so far.
MozReview-Commit-ID: F6fBP5R7ZTJ
--HG--
extra : rebase_source : f04bbf224ced7b93b4e5b0c42662731ecc58cb58
This adds a new highlighter in devtools/server/actors/highlighters.
For now this highlighter isn't used and can only display grid lines
as provided by node.getGridFragments().
Pages defining CSP response headers used to be a problem for the eyedropper.
Indeed, the eyedropper would take a screenshot of the window with
canvas.drawWindow and then load the resulting data as an Image. But in order
to access the Image() constructor, it would use the content window:
new window.Image(), and that wasn't possible with CSP headers.
With this change, the eyedropper creates an ImageBitmap with
window.createImageBitmap() and that doesn't cause CSP errors, and still works
fine because ImageBitmap are consumable by the eyedropper.
This change also adds a new test to prevent this bug from coming back.
MozReview-Commit-ID: 7f3HCXJtTiv
This adds a few new CSS selectors that are used to move the label to the
top and/or left/right of the eyedropper canvas.
The CSS rules use transform and a quick transition.
The eyedropper highlighter then just makes use of this by adding top, left,
right attributes to the DOM depending on its position.
This also adds a test for this, and while testing, I discovered a bug in
shared/layout/utils.js that I fixed here too. Sometimes, the node passed is
actually a DOCUMENT_NODE and so we must account for this in a couple of places
in this file to avoid JS errors.
MozReview-Commit-ID: H969k3mEDJE
MozReview-Commit-ID: 9qOCYVp4mld
Watch for browser swap events and update the message manager as necessary for
each of the actors that use the `setupInParent` multiprocess functionality.
MozReview-Commit-ID: HPibSONSYk4
It is now possible keep the toolbox open while toggling RDM open and closed.
The toolbox will follow the frame as it moves and update the message manager it
uses internally with each move.
MozReview-Commit-ID: DvLzCmOXfnb
Even though the pseudo :-moz-native-anonymous is only available for chrome content, elements
such as INPUT tags were impacted by the reset styles defined with the selector ":-moz-native-anonymous"
The selector has to be specialized in order to make sure it only impacts devtools elements.
MozReview-Commit-ID: HeHx9i6RJiq
--HG--
extra : rebase_source : e341a991c7583b855c66cdf2700b9ee9ed4c64a6
