Closed Bug 1455462 Opened Last year Closed Last year

When DevTools are zoomed in meatball menu and overflow menu are in the wrong place

Categories

(DevTools :: General, defect, P2)

defect

Tracking

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox60 unaffected, firefox61 verified, firefox62 verified)

VERIFIED FIXED
Firefox 62
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox60 --- unaffected
firefox61 --- verified
firefox62 --- verified

People

(Reporter: birtles, Assigned: mantaroh)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(13 files)

29.55 KB, image/png
Details
59 bytes, text/x-review-board-request
ochameau
: review+
Details
59 bytes, text/x-review-board-request
jdescottes
: review+
Details
59 bytes, text/x-review-board-request
jdescottes
: review+
Details
59 bytes, text/x-review-board-request
jdescottes
: review+
Details
59 bytes, text/x-review-board-request
jdescottes
: review+
Details
59 bytes, text/x-review-board-request
jdescottes
: review+
Details
695 bytes, patch
Details | Diff | Splinter Review
775 bytes, patch
Details | Diff | Splinter Review
3.79 KB, patch
Details | Diff | Splinter Review
2.87 KB, patch
Details | Diff | Splinter Review
5.91 KB, patch
Details | Diff | Splinter Review
4.09 KB, patch
Details | Diff | Splinter Review
Attached image Screenshot
No description provided.
It appears this affects the overflow menu too.
Summary: When DevTools are zoomed in meatball menu is in the wrong place → When DevTools are zoomed in meatball menu and overflow menu are in the wrong place
The tab bar of an inspector has the same problem as well.
I steal this bug.
Assignee: nobody → mantaroh
Status: NEW → ASSIGNED
This bug will affect the following panel:
 * toolbox's meatball menu. (toolbox-toolbar.js)
 * toolbox's frame select menu. (toolbox.js)
 * toolbox tab's chevron menu.  (toolbox-tabs.js)
 * Tab menu of inspector and network monitor. (TabBar.js)

In the current code, we use the viewport's pixel. The device pixel ratio will be increased if we zoom in devtools. We should use the device pixel ratio or zoom value for this calculation. Another code which using the Menu.popup is based on Event.screenX/Y(i.e. physical pixel), so we don't need to change these. (e.g. Behavior of right-clicking in the inspector.)

In addition to it, we should round the zoom value when zooming in/out since we need to calculate the position of the menu bar correctly. (e.g. 1.1 + 0.1 + 1.2000000000000002)[1]

[1] https://searchfox.org/mozilla-central/rev/fcd5cb3515d0e06592bba42e378f1b9518497e3d/devtools/client/shared/zoom-keys.js#51
Priority: -- → P2
If we use the popupAtScreen(), this popupAtScreen() will re-zoom out to the specified start position and add platform margin[1]. So menupopup position might out of position due to this offset of macOS is "-6".[2] So the test of this patches will allow the rounding error and this offset.

[1] https://searchfox.org/mozilla-central/rev/f30847c12e5fb13791401ed4330ced3e1b9c8d81/layout/xul/nsMenuPopupFrame.cpp#1504-1532
[2] https://searchfox.org/mozilla-central/rev/5ff2d7683078c96e4b11b8a13674daded935aa44/widget/cocoa/nsLookAndFeel.mm#505-507

Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7db5e4c7a3dc37a0e9ce2ad388b30b24eefaf4f4
Comment on attachment 8974242 [details]
Bug 1455462 - Part 1. Use the toolbox.zoomIn3.key shortcut.

https://reviewboard.mozilla.org/r/242544/#review248482

::: devtools/client/shared/zoom-keys.js:70
(Diff revision 1)
>      shortcuts.on(zoomIn2, zoomIn);
>    }
> -  let zoomIn3 = L10N.getStr("toolbox.zoomIn2.key");
> +  let zoomIn3 = L10N.getStr("toolbox.zoomIn3.key");
>    if (zoomIn3) {
>      shortcuts.on(zoomIn3, zoomIn);
>    }

Good catch!

I thought this key was used by some other locale, but it looks like it is not:
https://dxr.mozilla.org/l10n-central/search?q=toolbox.zoomIn3.key&redirect=false

So I think it is better to remove this for now, and remove "toolbox.zoomIn3.key" from locale files.
Attachment #8974242 - Flags: review?(poirot.alex) → review+
Comment on attachment 8974247 [details]
Bug 1455462 - Part 6. Add test of confirming the position of 'all menu' popup.

https://reviewboard.mozilla.org/r/242562/#review248510

Thanks for the patch! I would like to see another version without the id and without the hardcoded 29px. 
See my comments below and let me know if you have any question!

::: devtools/client/framework/test/browser_toolbox_zoom.js:63
(Diff revision 1)
>    await waitUntil(() => {
>      return hostWindow.screen.top === 0 &&
>        hostWindow.screen.left === 0 &&
>        hostWindow.outerWidth === 400 &&
> -      toolbox.doc.getElementById("tools-chevron-menu-button");
> +      toolbox.doc.getElementById("tools-chevron-menu-button") &&
> +      toolbox.getCurrentPanel().panelDoc.getElementById("all-tabs-menu-button");

I think for clarity it would be great to do a 

const inspector = toolbox.getCurrentPanel(); 

earlier, and reuse it here and a few lines below.

::: devtools/client/framework/test/browser_toolbox_zoom.js:76
(Diff revision 1)
>  
>    info("Check the all menus");
>    for (const menu of menuList) {
>      let [btnRect, menuRect] = await getButtonAndMenuRects(toolbox, menu);
>  
> +    // In this test. And we should consider the toolbox's height if target

Rather than toolbox, you might mean toolbar here? 

Now that I see this, I think you should use node.getBoxQuads({relativeTo});, using the toolbox document as "relativeTo". As the name suggests this will return coordinates relative to a specific document, not the node's document, which is exactly what we need here.

So instead of getBoundsWithoutFlushing, use

  let btnRect = menuButton.getBoxQuads({relativeTo: toolbox.doc})[0].bounds;
  let menuRect = menuPopup.getBoxQuads({relativeTo: toolbox.doc})[0].bounds;
  
(feel free to cleanup/refactor)  
We can assume the elements being tested here only have one quad.

Then you can get rid of toolboxHeight and the hardcoded 29px

::: devtools/client/shared/components/tabs/Tabs.js:330
(Diff revision 1)
>        // Display the menu only if there is not enough horizontal
>        // space for all tabs (and overflow happened).
>        let allTabsMenu = this.state.overflow ? (
>          dom.div({
>            className: "all-tabs-menu",
> +          id: "all-tabs-menu-button",

This is a shared component, we should never set a unique id here because it might be displayed several times in the same document. 

We should rely on a className based selector in the test.
Attachment #8974247 - Flags: review?(jdescottes)
Comment on attachment 8974246 [details]
Bug 1455462 - Part 5. Add toolbox's menu position test.

https://reviewboard.mozilla.org/r/242560/#review248490

This is a nice test, thanks Mantaroh! 

Clearing the review flag because I had a few suggestions and I should probably take another look once they are addressed.

::: devtools/client/framework/test/browser_toolbox_zoom.js:12
(Diff revision 1)
>  
>  const {LocalizationHelper} = require("devtools/shared/l10n");
>  const L10N = new LocalizationHelper("devtools/client/locales/toolbox.properties");
>  
> +// Use simple URL in order to prevent displacing the left positon of frames menu.
> +const TEST_URL = "data:text/html,<iframe/>";

We should add the charset 

"data:text/html;charset=utf-8,<iframe/>"

::: devtools/client/framework/test/browser_toolbox_zoom.js:16
(Diff revision 1)
> +// Use simple URL in order to prevent displacing the left positon of frames menu.
> +const TEST_URL = "data:text/html,<iframe/>";
> +
>  add_task(async function() {
> +  // This test assume that zoom value will be default value. i.e. x1.0.
> +  Services.prefs.setCharPref("devtools.toolbox.zoomValue", "1.0");

We should add a registerCleanupFunction that calls clearUserPref here

registerCleanupFunction(function() {
  Services.prefs.clearUserPref("devtools.toolbox.zoomValue");
});

::: devtools/client/framework/test/browser_toolbox_zoom.js:33
(Diff revision 1)
>    await toolbox.destroy();
>    gBrowser.removeCurrentTab();
> -  finish();
>  });
>  
> +add_task(async function() {

This test is specific enough to go in its own file

::: devtools/client/framework/test/browser_toolbox_zoom.js:35
(Diff revision 1)
> -  finish();
>  });
>  
> +add_task(async function() {
> +  const zoom = 1.5;
> +  Services.prefs.setCharPref("devtools.toolbox.zoomValue", zoom.toString(10));

same comment about registerCleanupFunction, after this is moved to a separate file.

::: devtools/client/framework/test/browser_toolbox_zoom.js:43
(Diff revision 1)
> +  await addTab(TEST_URL);
> +  let target = TargetFactory.forTab(gBrowser.selectedTab);
> +  let toolbox = await gDevTools.showToolbox(target,
> +                                            "inspector",
> +                                            Toolbox.HostType.WINDOW);
> +  let windowUtils = toolbox.win.QueryInterface(Ci.nsIInterfaceRequestor)

Can we add an info() before waiting here. We should log something like: "Waiting for the toolbox window to be rendered with zoom 1.5"

::: devtools/client/framework/test/browser_toolbox_zoom.js:69
(Diff revision 1)
> +
> +  let menuList = ["toolbox-meatball-menu-button",
> +                  "command-button-frames",
> +                  "tools-chevron-menu-button"];
> +
> +  info("Check the all menus");

nit: "Check all the menus" maybe ?

::: devtools/client/framework/test/browser_toolbox_zoom.js:81
(Diff revision 1)
> +  let onResize = once(hostWindow, "resize");
> +  hostWindow.resizeTo(originWidth, originHeight);
> +  await onResize;

It would be better to have this as a callback registered wia registerCleanupFunction in the beginning of the test. 

This way if the test fails/crashes/times out, we will still restore the window dimensions properly.

::: devtools/client/framework/test/browser_toolbox_zoom.js:84
(Diff revision 1)
> +  }
> +
> +  let onResize = once(hostWindow, "resize");
> +  hostWindow.resizeTo(originWidth, originHeight);
> +  await onResize;
> +  Services.prefs.setCharPref("devtools.toolbox.zoomValue", "1.0");

if you apply my suggestion about clearUserPref, this can be removed.

::: devtools/client/framework/test/browser_toolbox_zoom.js:114
(Diff revision 1)
>    let windowUtils = toolbox.win.QueryInterface(Ci.nsIInterfaceRequestor)
>      .getInterface(Ci.nsIDOMWindowUtils);
>    return windowUtils.fullZoom;
>  }
> +
> +async function getButtonAndMenuRects(toolbox, btnId) {

Can you add a comment explaining that this method will click on the button with the provided id, and return the rects of both the button and the associated popup?

::: devtools/client/framework/test/browser_toolbox_zoom.js:115
(Diff revision 1)
>      .getInterface(Ci.nsIDOMWindowUtils);
>    return windowUtils.fullZoom;
>  }
> +
> +async function getButtonAndMenuRects(toolbox, btnId) {
> +  let doc = toolbox.win.document;

nit: could use toolbox.doc as a shortcut here

::: devtools/client/framework/test/browser_toolbox_zoom.js:129
(Diff revision 1)
> +  });
> +  ok(menuPopup, "Menu popup is displayed.");
> +
> +  let windowUtils = toolbox.win.QueryInterface(Ci.nsIInterfaceRequestor)
> +      .getInterface(Ci.nsIDOMWindowUtils);
> +  let btnRect = windowUtils.getBoundsWithoutFlushing(menuButton);

Didn't know about getBoundsWithoutFlushing (and it looks interesting for performance!). 

Edit: see my comment in review of part6: I think we should use getBoxQuads here.
Attachment #8974246 - Flags: review?(jdescottes)
Comment on attachment 8974245 [details]
Bug 1455462 - Part 4. Use the async_task in devtool's zoom test.

https://reviewboard.mozilla.org/r/242558/#review248488

Thanks a lot for the cleanup, it's great to get rid of old-style tests :)

::: devtools/client/framework/test/browser_toolbox_zoom.js:6
(Diff revision 1)
>  /* Any copyright is dedicated to the Public Domain.
>   * http://creativecommons.org/publicdomain/zero/1.0/ */
>  
>  "use strict";
>  
> -var toolbox;
> +let {Toolbox} = require("devtools/client/framework/toolbox");

nit: Could we use const here?

::: devtools/client/framework/test/browser_toolbox_zoom.js:26
(Diff revision 1)
> -  testZoomLevel("Out", 3, 0.9);
> -  testZoomLevel("Reset", 1, 1);
> +  testZoomLevel("Out", 3, 0.9, toolbox);
> +  testZoomLevel("Reset", 1, 1, toolbox);
>  
> -  tidyUp();
> -}
> +  await toolbox.destroy();
> +  gBrowser.removeCurrentTab();
> +  finish();

Thanks to using add task, you no longer need to call finish() here normally.
Attachment #8974245 - Flags: review?(jdescottes) → review+
Comment on attachment 8974244 [details]
Bug 1455462 - Part 3. Use zoom value when showing popup menu.

https://reviewboard.mozilla.org/r/242556/#review248524

Thanks for the fix! We should improve the documentation a bit, it's not clear when we should use open() or openWithZoom right now.

On a sidenote, we will need a similar fix in the HTMLTooltip, which sometimes relies on a XUL panel as well:
https://searchfox.org/mozilla-central/rev/5ff2d7683078c96e4b11b8a13674daded935aa44/devtools/client/shared/widgets/tooltip/HTMLTooltip.js#601

::: devtools/client/framework/menu.js:57
(Diff revision 1)
>  };
>  
>  /**
> + * Show the Menu with current zoom value.
> + */
> +Menu.prototype.popupWithZoom = function(screenX, screenY, toolbox) {

Can we add a comment to explain when this method should be used? 
- if we are getting the coordinates of an anchor element, then we should use this method because we ned to apply the zoom to convert the anchor coordinates to screen coordinates.
- if we already have screenX screenY from a mosue event for instance, we can directly use the existing API. 

The documentation should help the developer know which method to chose. Maybe also rename screenX, screenY in this method to (x, y) or (coordX, coordY) to suggest that what you pass to this method are not really screen coordinates.

::: devtools/client/framework/menu.js:58
(Diff revision 1)
>  
>  /**
> + * Show the Menu with current zoom value.
> + */
> +Menu.prototype.popupWithZoom = function(screenX, screenY, toolbox) {
> +  let zoom = parseFloat(Services.prefs.getCharPref("devtools.toolbox.zoomValue"));

Since "devtools.toolbox.zoomValue" is a char user pref, we don't really control which value it can have. We should probably add a guard here in case the pref has a an invalid value (e.g. NaN) ? Maybe worth adding a test case too.

eg. if (!zoom || isNaN(zoom)) { zoom = 1 }
or something similar.
Attachment #8974244 - Flags: review?(jdescottes) → review+
Comment on attachment 8974243 [details]
Bug 1455462 - Part 2. Use the rounded zoom value of devtool panel.

https://reviewboard.mozilla.org/r/242546/#review248528

Good catch, thanks! Could use a comment to clarify.

::: devtools/client/shared/zoom-keys.js:53
(Diff revision 1)
>  
>    let setZoom = function(newValue) {
>      // cap zoom value
>      zoomValue = Math.max(newValue, MIN_ZOOM);
>      zoomValue = Math.min(zoomValue, MAX_ZOOM);
> +    zoomValue = Math.round(zoomValue * 10) / 10;

Can we add a comment explaining why this is needed?
For instance say that "1.3 + 0.1" returns 1.4000000000000001, and that's why we should sanitize the value
Attachment #8974243 - Flags: review?(jdescottes) → review+
See Also: → 1460467
Comment on attachment 8974242 [details]
Bug 1455462 - Part 1. Use the toolbox.zoomIn3.key shortcut.

https://reviewboard.mozilla.org/r/242544/#review248482

> Good catch!
> 
> I thought this key was used by some other locale, but it looks like it is not:
> https://dxr.mozilla.org/l10n-central/search?q=toolbox.zoomIn3.key&redirect=false
> 
> So I think it is better to remove this for now, and remove "toolbox.zoomIn3.key" from locale files.

Thanks. I filed it as follow up bug 1460467 of this.
Comment on attachment 8974244 [details]
Bug 1455462 - Part 3. Use zoom value when showing popup menu.

https://reviewboard.mozilla.org/r/242556/#review248524

Thanks.

Ah, yes. I checked inspector's tooltip. This tooltip has the same problem. So I'll fix it on another bug.
Comment on attachment 8974246 [details]
Bug 1455462 - Part 5. Add toolbox's menu position test.

https://reviewboard.mozilla.org/r/242560/#review248490

> nit: "Check all the menus" maybe ?

Sorry, This is debugging output. I'll remove it.

> It would be better to have this as a callback registered wia registerCleanupFunction in the beginning of the test. 
> 
> This way if the test fails/crashes/times out, we will still restore the window dimensions properly.

It seems to me that test target window will close in this step(i.e. cleanup function). If I add this code to the cleanup function, fail to resizeTo() function.

> Didn't know about getBoundsWithoutFlushing (and it looks interesting for performance!). 
> 
> Edit: see my comment in review of part6: I think we should use getBoxQuads here.

OK. I addressed this byt using the getBoxQuads.
Comment on attachment 8974247 [details]
Bug 1455462 - Part 6. Add test of confirming the position of 'all menu' popup.

https://reviewboard.mozilla.org/r/242562/#review249004

Looks good to me! Thanks Mantaroh.

::: devtools/client/framework/test/browser_toolbox_zoom_popup.js:47
(Diff revision 2)
>    await waitUntil(() => {
>      return hostWindow.screen.top === 0 &&
>        hostWindow.screen.left === 0 &&
>        hostWindow.outerWidth === 400 &&
> -      toolbox.doc.getElementById("tools-chevron-menu-button");
> +      toolbox.doc.getElementById("tools-chevron-menu-button") &&
> +      inspector.panelDoc.querySelectorAll(".all-tabs-menu")[0];

nit: you can replace inspector.panelDoc.querySelectorAll(".all-tabs-menu")[0] with inspector.panelDoc.querySelector(".all-tabs-menu")
Attachment #8974247 - Flags: review?(jdescottes) → review+
Comment on attachment 8974246 [details]
Bug 1455462 - Part 5. Add toolbox's menu position test.

https://reviewboard.mozilla.org/r/242560/#review249006

Test looks great, thanks! There is a frequent intermittent failure to address. Giving the r+ here, ping me if you need help fixing the issue.

::: devtools/client/framework/test/browser_toolbox_zoom_popup.js:6
(Diff revision 2)
> +/* Any copyright is dedicated to the Public Domain.
> + * http://creativecommons.org/publicdomain/zero/1.0/ */
> +
> +"use strict";
> +
> +const {Toolbox} = require("devtools/client/framework/toolbox");

Can we add a top-level comment to describe what we are testing here?

::: devtools/client/framework/test/browser_toolbox_zoom_popup.js:60
(Diff revision 2)
> +    // Allow rounded error and platform offset value.
> +    // horizontal : eIntID_ContextMenuOffsetHorizontal of GTK and Windows uses 2.
> +    // vertical: eIntID_ContextMenuOffsetVertical of macOS uses -6.
> +    ok(Math.abs(menuRect.left - btnRect.left) < 2 &&
> +       Math.abs(menuRect.top - btnRect.bottom) < 6,
> +       "Menu has been displayed under the button. #" + menu);

I get failures here while running the test with "--verify". It fails on the chevron button.

1/ we should print menu.id, and not just menu
2/ it might be interesting to log a bit more info, e.g.

  let xDelta = Math.abs(menuRect.left - btnRect.left);
  let yDelta = Math.abs(menuRect.top - btnRect.bottom);
  ok(xDelta < 2, "xDelta is lower than 2: " + xDelta + ". #" + menu.id);
  ok(yDelta < 6, "yDelta is lower than 6: " + yDelta + ". #" + menu.id);
  
This will help understand the failures.

3/ We should fix this before landing. Given how frequent it is on my machine I think it will fail at a high frequency on CI and might lead to a backout. Even though the window is resized and the chevron is displayed, the chevron menu opens at the location of the chevron _before_ the window resize. Maybe we need to wait for another render, or to wait until the chevron button is rendered at reasonable coordinates (checking that the rect.x is below 400 (taking zoom into account) maybe?
Attachment #8974246 - Flags: review?(jdescottes) → review+
Comment on attachment 8974246 [details]
Bug 1455462 - Part 5. Add toolbox's menu position test.

https://reviewboard.mozilla.org/r/242560/#review249006

Thanks!

> I get failures here while running the test with "--verify". It fails on the chevron button.
> 
> 1/ we should print menu.id, and not just menu
> 2/ it might be interesting to log a bit more info, e.g.
> 
>   let xDelta = Math.abs(menuRect.left - btnRect.left);
>   let yDelta = Math.abs(menuRect.top - btnRect.bottom);
>   ok(xDelta < 2, "xDelta is lower than 2: " + xDelta + ". #" + menu.id);
>   ok(yDelta < 6, "yDelta is lower than 6: " + yDelta + ". #" + menu.id);
>   
> This will help understand the failures.
> 
> 3/ We should fix this before landing. Given how frequent it is on my machine I think it will fail at a high frequency on CI and might lead to a backout. Even though the window is resized and the chevron is displayed, the chevron menu opens at the location of the chevron _before_ the window resize. Maybe we need to wait for another render, or to wait until the chevron button is rendered at reasonable coordinates (checking that the rect.x is below 400 (taking zoom into account) maybe?

OK. I added (1 and (2.

This test resize the window size. In this test failure case, run an updating overflowed tab process between getting the chevron button element and checking the chevron element position. As result of it, test is failed.

An easy solution is that waiting for updating the tab. I addressed it.


Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f24409aa0f72aa14f78d1b6c351d8000f81d3627
Comment on attachment 8974247 [details]
Bug 1455462 - Part 6. Add test of confirming the position of 'all menu' popup.

https://reviewboard.mozilla.org/r/242562/#review249004

Thanks for the review.
See Also: → 1460795
Pushed by mantaroh@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/8e3a5591905b
Part 1. Use the toolbox.zoomIn3.key shortcut. r=ochameau
https://hg.mozilla.org/integration/autoland/rev/0530a5377197
Part 2. Use the rounded zoom value of devtool panel. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/6d6065b44f12
Part 3. Use zoom value when showing popup menu. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/d130f6c97791
Part 4. Use the async_task in devtool's zoom test. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/24cc4156d7c4
Part 5. Add toolbox's menu position test. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/17454360b8c5
Part 6. Add test of confirming the position of 'all menu' popup. r=jdescottes
I'd like to uplift this changes.
The patch 3 of this series is rebased since bug 1452060 doesn't uplift.

[Feature/regressing bug #]: N/A
[User impact if declined]: If the user zoomed in/out the panel, the user can't find the popup menu. It might make poor operability.
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: No
[Is the change risky?]:  Low. This change is limited, and these operation and behavior are confirmed by using browser test.
[Why is the change risky/not risky?]: see above.
[String changes made/needed]: N/A
Attachment #8975681 - Flags: approval-mozilla-beta?
Attachment #8975682 - Flags: approval-mozilla-beta?
Attachment #8975683 - Flags: approval-mozilla-beta?
Attachment #8975685 - Flags: approval-mozilla-beta?
Attachment #8975686 - Flags: approval-mozilla-beta?
Comment on attachment 8975681 [details] [diff] [review]
bug1455462-part-1-zoom-key-map

Fixes a new devtools UI regression in 61 and includes a new automated test. Approved for 61.0b6.
Attachment #8975681 - Attachment is patch: true
Attachment #8975681 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8975682 - Attachment is patch: true
Attachment #8975682 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8975683 - Attachment is patch: true
Attachment #8975683 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8975684 - Attachment is patch: true
Attachment #8975684 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8975685 - Attachment is patch: true
Attachment #8975685 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #8975686 - Attachment is patch: true
Attachment #8975686 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Product: Firefox → DevTools
I have reproduced this issue using Firefox 61.0a1 (2018.04.19) on Mac 10.13.
I can confirm this issue is fixed, I verified using Firefox 61.0b14 and 62.0a1 on Win 8.1 x64, Ubuntu 14.04 x64 and Mac OS X 10.11.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.