1144163 - Add a rulers highlighter

Status: RESOLVED FIXED

(DevTools :: Inspector, defect)

Description

[Matteo Ferretti [:zer0] [:matteo]]

Having the capability to displays lightweight horizontal and vertical rules on the page, could be very handy for designers.

Comment 1

[Patrick Brosset <:pbro>]

Sorry for closing this bug just after you created it :) but we already had one bug for this: bug 1089240
And it already has some nice icons for the toolbar command.

Comment 2

[Patrick Brosset <:pbro>]

Oops sorry, I was too quick, this other bug is more about a measurement tool in fact.

Comment 3

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rules.patch

It's still a bit a WIP, that's why I added you for feedback, but I think it's the right way to do for having the rules as highlighter, without too much changing on platform side.
As we talk, the canvas approach is not feasible at the moment, so I fallback again to SVG. Unfortunately, the <pattern> are broken in the anonymous content, we probably should file a bug about it, so I ended up do dynamically create a path with all the segment we need. The downside is, for the moment, we need a fixed size for each rules.

Currently the zoom is not handled, but I used a workaround to have the line's path width always 1px; it's better than before, and I think it's a good tradeoff / starting point.

Comment 4

[Patrick Brosset <:pbro>]

Comment on attachment 8578711 [details] [diff] [review]
rules.patch

Review of attachment 8578711 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch.
I have one general comment first before going into the details: the correct name should be "ruler" instead of "rule". So the command file name should be changed, and the command name and highlight class too.

Other than this, I've applied the patch locally and played with it. It works nicely.
About the 2 limitations:
- fixed size: I was able to get to the end of the vertical ruler only on a huuuuge page, and I don't think that's a problem that should prevent landing. I'm guessing that most of the use cases for this tool is going to be when users work on mockups or template pages that don't necessarily have huge content in them. I don't really see a need for measuring stuff at 20000px below the top of the page. So I'm OK with it, and we can file a follow-up bug to investigate ways to make this infinite (can you file the bug please? make it depend on this one, and CC me on it please).
- zooming: not a big deal either. The dimension adapt correctly, and the graduations stay sharp. So the only problem is that the ruler and text becomes bigger. But again, we can live with this and file a follow-up bug for it too (same as before, could you please file and cc me on it?)

Last, we need tests for this. First of all, we need a command test that really just tests the output of the command and the autocompletion when given various inputs.
See /browser/devtools/commandline/test/browser_cmd_highlight_01.js for an example
And we need tests for the highlighter itself. All our highligther-related tests are in /browser/devtools/inspector/test and the filenames all start with browser_inspector_highlighter*
You can look at the ones I've added for the geometry highlighter recently for instance.

::: browser/locales/en-US/chrome/browser/devtools/gclicommands.properties
@@ +1536,5 @@
> +rulesDesc=Toggle rulers for the page
> +
> +# LOCALIZATION NOTE (rulesManual) A fuller description of the 'rules'
> +# command, displayed when the user asks for help on what it does.
> +rulesManual=Toggle rulers for the current page

Maybe elaborate a bit more, like: "Toggle the horizontal and vertical rulers for the current page"

::: toolkit/devtools/gcli/commands/rules.js
@@ +1,4 @@
> +/* This Source Code Form is subject to the terms of the Mozilla Public
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +

One global comment about this command: Joe is currently working on making gcli e10s ready (bug 1128988). And for this, existing commands have to be migrated.
He's not entirely done with the task, but should be this week (no promises though).
So, either we land this command as it is now, and that means someone will have to migrate it to the new gcli very soon. Or, we hold off for maybe a week, maybe more, before landing it and we make it e10s ready.

::: toolkit/devtools/server/actors/highlighter.css
@@ +214,5 @@
>  }
> +
> +/* Rules highlighter */
> +
> +:-moz-native-anonymous #rules-highlighter-elements {

Nothing prevents the highlighter from being instantiated several times in the same window. Not that this should happen, but still, I think you should use classes in these rules, instead of IDs.

@@ +224,5 @@
> +}
> +
> +:-moz-native-anonymous #rules-highlighter-x-axis-ruler > path,
> +:-moz-native-anonymous #rules-highlighter-y-axis-ruler > path {
> +  stroke-width: 0.0001;

Is this the hack you mentioned earlier that makes sure the lines are always 1px wide?
If so, this needs a comment block before it, explaining why we did this.

::: toolkit/devtools/server/actors/highlighter.js
@@ +47,5 @@
>  // Distance of the width or height handles from the node's edge.
>  const GEOMETRY_SIZE_ARROW_OFFSET = .25; // 25%
>  const GEOMETRY_LABEL_SIZE = 6;
>  
> +const MAX_X_AXIS = 10000;

Can you precede these 2 const by a comment explaining which highlighter needs them and what they do.

@@ +2420,5 @@
>  exports.GeometryEditorHighlighter = GeometryEditorHighlighter;
>  
>  /**
> + * The RulesHighlighter is a class that displays both horizontal and
> + * vertical rules on the page.

Maybe elaborate: "... along the top and left edges, with pixel graduations, useful for users to quickly check distances"

@@ +2427,5 @@
> +  this.win = tabActor.window;
> +  this.markup = new CanvasFrameAnonymousContentHelper(tabActor,
> +    this._buildMarkup.bind(this));
> +
> +  this.win.addEventListener("scroll", this, true);

Can you removeEventListener in the destroy method?

@@ +2451,5 @@
> +        width = 16;
> +        height = size;
> +        isHorizontal = false;
> +      } else {
> +        throw new Error("Invalid type of axis given")

It's nice to add an error with a message here. That helps.
It would help even more if it said:
`Invalid type of axis given, expected "x" or "y", but got "${axis}"`

@@ +2458,5 @@
> +      let g = createSVGNode(window, {
> +        nodeType: "g",
> +        attributes: {
> +          id: `${axis}-axis`,
> +          style: "opacity: 0.8"

Can you move this style to the highlighter.css stylesheet instead? Giving this <g> element a class.

@@ +2469,5 @@
> +        nodeType: "rect",
> +        attributes: {
> +          width,
> +          height,
> +          fill: "#fff"

Same comment here.

@@ +2488,5 @@
> +        nodeType: "path",
> +        attributes: {
> +          width,
> +          height,
> +          stroke: "#bebebe"

Same comment here.

@@ +2493,5 @@
> +        },
> +        parent: gRule
> +      });
> +
> +      let pathMarker = createSVGNode(window, {

Reading the code, it's hard to tell the difference between path and pathMarker, I think they need more descriptive variable names, or at least a comment line explaining why we have 2 and which does what.

@@ +2498,5 @@
> +        nodeType: "path",
> +        attributes: {
> +          width,
> +          height,
> +          stroke: "#202020"

Same comment about moving this style to the CSS.

@@ +2514,5 @@
> +      });
> +
> +      let d = "";
> +      let dMarker = "";
> +      let l = 4;

Also a more descriptive name for this one letter variable would help.

@@ +2521,5 @@
> +        if (i === 0) continue;
> +
> +        l = (i % 2 === 0) ? 6 : 4;
> +
> +        if (i % 100 === 0) {

The numbers 100 here and 50 further below should be defined as named constants instead. This will also help in the future if we want to make this work with other units.

@@ +2537,5 @@
> +        if (isHorizontal) {
> +          d += `M${i} 0 L${i} ${l} `;
> +
> +          if (i % 50 === 0)
> +            dMarker += `M${i} 0 L${i} ${l}`;

So, in this case (same for vertical), the dMarker covers up the d, right?
If yes, you should probably only draw one, this would reduce the length of the d parameter.

@@ +2556,5 @@
> +    let container = createNode(window, {
> +      attributes: {"class": "highlighter-container"}
> +    });
> +
> +    // Build the root wrapper, used to adapt to the page zoom.

This comment should be removed, since you're not adapting to zoom yet.

@@ +2573,5 @@
> +      attributes: {
> +        "id": "elements",
> +        "width": "100%",
> +        "height": "100%",
> +        //"hidden": "true"

I think it should be hidden by default, until the show method is called.
We may want to instantiate it and only later show it.

@@ +2585,5 @@
> +    return container;
> +  },
> +
> +  handleEvent: function(event) {
> +    switch(event.type) {

nit: space between switch and (

@@ +2598,5 @@
> +
> +    this.markup.setAttributeForElement(prefix + "x-axis-ruler", "transform", `translate(${-scrollX})`);
> +    this.markup.setAttributeForElement(prefix + "x-axis-text", "transform", `translate(${-scrollX})`);
> +    this.markup.setAttributeForElement(prefix + "y-axis-ruler", "transform", `translate(0, ${-scrollY})`);
> +    this.markup.setAttributeForElement(prefix + "y-axis-text", "transform", `translate(0, ${-scrollY})`);

formatting nit: please split lines after 80 chars.

Also, defining a getElement method on the class may help:

getElement: function(id) {
  return this.markup.getElement(this.ID_CLASS_PREFIX + id);
},

and then change your code to do:

this.getElement("x-axis-ruler").setAttribute("transform", `translate(${-scrollX})`);

Comment 5

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers highlighter

Comment 6

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers gcli command

Comment 7

[Patrick Brosset <:pbro>]

Comment on attachment 8583802 [details] [diff] [review]
rulers highlighter

Review of attachment 8583802 [details] [diff] [review]:
-----------------------------------------------------------------

Cool, this new highlighter class looks good to me.
I know tests are coming as a separate patch, so this one is ok as is.

Comment 8

[Patrick Brosset <:pbro>]

Comment on attachment 8583804 [details] [diff] [review]
rulers gcli command

Review of attachment 8583804 [details] [diff] [review]:
-----------------------------------------------------------------

Nice and simple, thanks.
Let's add the necessary code to turn that into a toolbar button soon-ish, so that's it's more discoverable.

::: browser/devtools/commandline/commands-index.js
@@ +24,5 @@
>    "gcli/commands/paintflashing",
>    "gcli/commands/restart",
>    "gcli/commands/screenshot",
>    "gcli/commands/tools",
> +  "gcli/commands/rulers"

Please keep the list in alphabetical order, this entry should come just before screenshot.

Comment 9

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers highlighter tests

Comment 10

[Patrick Brosset <:pbro>]

Comment on attachment 8584467 [details] [diff] [review]
rulers highlighter tests

Review of attachment 8584467 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. R+. No need to ask me for another review, but I still have 2 minor change requests:
- split the test in 2
- add a response message in the message listener when the input is invalid

::: browser/devtools/inspector/test/browser_inspector_highlighter-rulers_01.js
@@ +26,5 @@
> +  let highlighter = yield front.getHighlighterByType("RulersHighlighter");
> +
> +  yield isHiddenByDefault(highlighter, inspector);
> +  yield hasRightLabelsContent(highlighter, inspector);
> +  yield isUpdatedAfterScroll(highlighter, inspector);

In order to keep this test small, please move this function into a new test browser_inspector_highlighter-rulers_02.js
The scroll test is quite long so it's a candidate to be in a test on its own.

::: browser/devtools/inspector/test/doc_frame_script.js
@@ +310,5 @@
> +addMessageListener("Test:ScrollWindow", function(msg) {
> +  let {x, y, relative} = msg.data;
> +
> +  if (isNaN(x) || isNaN(y))
> +    return;

The problem with doing an early return here is that the test that sent this message will wait forever for the response message until it times out.
I think you should send a message back in this case too, but maybe setting the response data to null or something, so that the test can know something went wrong and can fail properly instead of timing out.

Comment 11

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers' button for toolbox

Comment 12

[Matteo Ferretti [:zer0] [:matteo]]

Patrick, I addressed all the comments you made. At the moment I have the patch split as follow: a changeset for the rulers highlighter, one for the highlighter tests, one for the command line (both implementation and tests), and one for the toolbox button.

Once you took a look to the button one; should I squash all those commits in just one, and attach only the result patch? What's usually the best practice in devtools?

Comment 13

[Patrick Brosset <:pbro>]

Comment on attachment 8584770 [details] [diff] [review]
rulers' button for toolbox

Review of attachment 8584770 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. I'm just removing the R? flag and waiting for a new patch that handles page navigation, as discussed.

::: browser/app/profile/firefox.js
@@ +1384,5 @@
>  pref("devtools.command-button-scratchpad.enabled", false);
>  pref("devtools.command-button-responsive.enabled", true);
>  pref("devtools.command-button-eyedropper.enabled", false);
>  pref("devtools.command-button-screenshot.enabled", false);
> +pref("devtools.command-button-rulers.enabled", false);

For info, I just filed bug 1149171 to avoid having to add a pref whenever we create a new button.

::: toolkit/devtools/gcli/commands/rulers.js
@@ +20,5 @@
>      manual: gcli.lookup("rulersManual"),
> +    buttonId: "command-button-rulers",
> +    buttonClass: "command-button command-button-invertable",
> +    tooltipText: gcli.lookup("rulersTooltip"),
> +    state: {

As discussed on IRC, let's handle page navigation cases here too.

Comment 14

[Patrick Brosset <:pbro>]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #12)
> Patrick, I addressed all the comments you made. At the moment I have the
> patch split as follow: a changeset for the rulers highlighter, one for the
> highlighter tests, one for the command line (both implementation and tests),
> and one for the toolbox button.
> 
> Once you took a look to the button one; should I squash all those commits in
> just one, and attach only the result patch? What's usually the best practice
> in devtools?
No need to squash commits together after review for landing. As long as your commits make sense individually (i.e. it is possible to build and run firefox at any point in the history), then landing a series of patches, one for each commit, is fine.

Comment 15

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers highlighter

The only change compared to the previous patch is the "pagehide" event that destroy the highlighter, and the "destroy" event emitted by the highlighters itself.

Comment 16

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers gcli command

The patch now address the navigation issue for the gcli. I also unified the gcli related patch (command and button).

Comment 17

[Patrick Brosset <:pbro>]

Comment on attachment 8586052 [details] [diff] [review]
rulers gcli command

Review of attachment 8586052 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me.
A couple of comments:
- Can you file a meta bug to re-group this bug and all the follow ups we've been discussing: handle zoom, really long pages, and page navigation problems
- The icon in the toolbar doesn't look like other toolbar icons, I see a subtle difference, maybe that's just me, but I find the icon dark than the other ones. With the light theme for instance, it's really hard to see the hover state. I see the icon almost as black, and I don't really see it change color when I hover over it. I see the other icons a little bit lighter and the difference between default and hover state easier to see.
I've made a screenshot to show this: https://dl.dropboxusercontent.com/u/714210/dark-icon.png
In this screenshot, the first line shows 3 toolbar icons, with no hover effects,
the second line shows the same icons, with the eye-dropper being hovered,
and the third, with the rulers icon hovered.
If I measure the darkest color of other icons when they aren't hovered, I find #555550. But #3b3b3b with the rulers.
And when hovered, the darkest color of other icons is #352e2e, but #232323 for the rulers.

::: toolkit/devtools/gcli/commands/rulers.js
@@ +58,5 @@
> +        browser: env.chromeWindow.gBrowser.getBrowserForDocument(env.document),
> +        window: env.window
> +      };
> +
> +      let emitToContext = (type, data) => 

nit: trailing whitespaces.

@@ +71,5 @@
> +
> +      events.once(highlighter, "destroy", () => {
> +        if (highlighters.has(env.document)) {
> +          let { highlighter, listener } = highlighters.get(env.document);
> +          

nit: trailing whitespaces.

Comment 18

[Patrick Brosset <:pbro>]

One last thing, the commit messages of 2 of the patches don't have the suffix "; r=pbrosset". Make sure to add that before landing or asking for check-in.

Comment 19

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers gcli command

Comment 20

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers highlighter tests

Comment 21

[Patrick Brosset <:pbro>]

(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #17)
> If I measure the darkest color of other icons when they aren't hovered, I
> find #555550. But #3b3b3b with the rulers.
In the new patch, I see the non-hovered rulers' icon darkest color being #464647, so it's lighter than in the previous patch, but not as light as the other icons (eye dropper, split-console). I have tested with other icons, and it turns out the screenshot icon is also a lot darker than the others. So we're not consistent here. That's why I R+'d the patch, I don't want to hold it for this, but I think we need someone to review our icons, now that we have a lot, and make sure they're consistently colored.

Comment 22

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers gcli command

(In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #21)

> In the new patch, I see the non-hovered rulers' icon darkest color being
> #464647, so it's lighter than in the previous patch, but not as light as the
> other icons (eye dropper, split-console).

I think it's still an issue with the color profile. Now it should be OK.

Comment 23

[Matteo Ferretti [:zer0] [:matteo]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=734a19be9847

Comment 24

[Matteo Ferretti [:zer0] [:matteo]]

It seems there are some issue in the build on try server, but unrelated to this patch.

Comment 25

[Carsten Book [:Tomcat]]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #22)
> Created attachment 8586147 [details] [diff] [review]
> rulers gcli command
> 
> (In reply to Patrick Brosset [:pbrosset] [:patrick] from comment #21)
> 
> > In the new patch, I see the non-hovered rulers' icon darkest color being
> > #464647, so it's lighter than in the previous patch, but not as light as the
> > other icons (eye dropper, split-console).
> 
> I think it's still an issue with the color profile. Now it should be OK.

Seems this didn't apply :

adding 1144163 to series file
renamed 1144163 -> rulers-gcli-4.patch
applying rulers-gcli-4.patch
patching file browser/themes/windows/jar.mn
Hunk #2 FAILED at 771
1 out of 2 hunks FAILED -- saving rejects to file browser/themes/windows/jar.mn.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh rulers-gcli-4.patch

Comment 26

[Matteo Ferretti [:zer0] [:matteo]]

Attachment: rulers gcli command

Comment 27

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/fx-team/rev/b47c1d1a7587
https://hg.mozilla.org/integration/fx-team/rev/757b57608b15
https://hg.mozilla.org/integration/fx-team/rev/bff8313febf0

Comment 28

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/b47c1d1a7587
https://hg.mozilla.org/mozilla-central/rev/757b57608b15
https://hg.mozilla.org/mozilla-central/rev/bff8313febf0

Comment 29

[Francesco Lodolo [:flod]]

You really should re-read the localization comments ;-)
http://hg.mozilla.org/mozilla-central/diff/bff8313febf0/browser/locales/en-US/chrome/browser/devtools/gclicommands.properties

    1.13 +# LOCALIZATION NOTE (rulesDesc) A very short description of the
    1.14 +# 'rules' command. See highlightManual for a fuller description of what
    1.15 +# it does. This string is designed to be shown in a menu alongside the
    1.16 +# command name, which is why it should be as short as possible.

'rules' -> 'rulers', rulesDesc -> rulersDesc.
The second sentence seems completely unrelated (bad copy and paste?).

    1.19 +# LOCALIZATION NOTE (rulesManual) A fuller description of the 'rules'
    1.20 +# command, displayed when the user asks for help on what it does.

Typo again.

    1.23 +# LOCALIZATION NOTE (rulersTooltip) A string displayed as the
    1.24 +# tooltip of button in devtools toolbox which toggles the rulers highligher.

I guess "highlighter", but I don't think it's actually needed.

Comment 30

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Francesco Lodolo [:flod] (UTC+2) from comment #29)

> You really should re-read the localization comments ;-)

You're right; I mistyped at the beginning the name in "rules" – see comment 4 – and I forgot to replace the localization note :(

I filed bug 1150819 to address your comments, and I've assigned the review to you.

Comment 31

[Tim Nguyen :ntim]

Release Note Request (optional, but appreciated)
[Why is this notable]: Cool new devtool
[Suggested wording]: New page ruler tool
[Links (documentation, blog post, etc)]: None yet, probably hacks.mo in the future

Comment 32

[Tim Nguyen :ntim]

Dev docs about the gcli command and the command button would be nice

Comment 33

[Will Bamberg [:wbamberg]]

I've added a new page for this: https://developer.mozilla.org/en-US/docs/Tools/Rulers, and updated the GCLI docs and the Settings page with info on how to enable the button.

Please let me know if there's anything else I need to add here.

Comment 34

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Will Bamberg [:wbamberg] from comment #33)
> I've added a new page for this:
> https://developer.mozilla.org/en-US/docs/Tools/Rulers, and updated the GCLI
> docs and the Settings page with info on how to enable the button.
> 
> Please let me know if there's anything else I need to add here.

Sorry, it totally slip under the radar! Looks good to me.

Comment 35

[Mihai Boldan, Desktop QA [:mboldan]]

 I've performed Exploratory Testing around this feature on Nightly 44.0a1 (20151018030250) across platforms [1] and managed to confirm the following:
- the ruler is displayed and it works overall as expected
- the ruler is also affected by zoom actions
- the ruler's size is currently limited at 15000px (width) x 10000px (height), although there's no label displayed for the exact ends of it (I assume this is expected)

One issue I've noticed during testing is that the 'rulers' command from the Developer Toolbar is not working, if 'Toggle rulers for the page' was previously enabled/disabled. It's reproducible across platforms [1], with and without e10s enabled.

Matteo, is this behavior expected?

[1] Windows 10 x86, Ubuntu 14.04 x86, Mac OS X 10.10.4

Comment 36

[Matteo Ferretti [:zer0] [:matteo]]

(In reply to Mihai Boldan, QA [:mboldan] from comment #35)

> One issue I've noticed during testing is that the 'rulers' command from the
> Developer Toolbar is not working, if 'Toggle rulers for the page' was
> previously enabled/disabled. It's reproducible across platforms [1], with
> and without e10s enabled.
> 
> Matteo, is this behavior expected?

No, is not expected, but I'm not able to reproduce on OS X (10.10.5) and Firefox Dev Edition (47). Is this still reproducible to you?

> 
> [1] Windows 10 x86, Ubuntu 14.04 x86, Mac OS X 10.10.4

Comment 37

[Mihai Boldan, Desktop QA [:mboldan]]

This issue is still reproducible on Firefox 47.0a2 (2016-03-21).

Here are STR for this issue:
1. Launch FF with a clean profile.
2. Enable Toogle tools (Ctrl+Shift+I).
3. Enable Developer Toolbar (Shift+F2).
4. Open Toolbox Options and enable 'Toogle rulers for the page' option.
5. Disable and re-enable the option from step 4.
6. Enable the Rulers by clicking on the rulers icon.
7. Disable the rulers by using the 'rulers' command in the Developer Toolbar.

ER: The rulers tool is disabled.

AR: Nothing happens.

I managed to reproduce this issue on Windows 10 x86, Mac OS X 10.11.1 and on Ubuntu 14.04 x86

Should I log a new bug for this issue?

Comment 38

[Matteo Ferretti [:zer0] [:matteo]]

Sorry Mihai, I totally forget about this. Is the issue still reproducible? In this case, could you file a new bug about that, and set that it blocks inspector/rulers bug? (https://bugzilla.mozilla.org/show_bug.cgi?id=%20inspector%2Frulers)

Thanks!

Comment 39

[Mihai Boldan, Desktop QA [:mboldan]]

(In reply to Matteo Ferretti [:zer0] [:matteo] from comment #38)
> Sorry Mihai, I totally forget about this. Is the issue still reproducible?
> In this case, could you file a new bug about that, and set that it blocks
> inspector/rulers bug?
> (https://bugzilla.mozilla.org/show_bug.cgi?id=%20inspector%2Frulers)
> 
> Thanks!

Added Bug 1340553 for the issue mentioned in Comment 37.