1602783 - The dimensions we have thanks to the rulers for the page disappear after a refresh of a page

Status: VERIFIED FIXED

(DevTools :: Inspector, defect, P2)

Description

[spip931]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

For starters, you need to toggle rulers for the page in the mozilla development tool.
For that, you have to do ctrl + i. Then click on the 3 small dot at the top right of the mozilla development toolbar.
In the Available Toolbox Buttons section, check "Toggle rulers for the page".
Return to the Inspector tab.
Click on the Toggle rulers for the page icon. The icon turns blue to indicate that the rules are displayed. The dimensions of the page appear in pixels.
Then we refresh the page (ctrl + F5).

Actual results:

The page refreshes, the "Toggle rulers for the page" icon is always blue (so normally active). However, we no longer see the dimensions of the page in pixels.
If we click on the Toggle rulers for the page icon to deactivate them, and we click on them to re-activate them, it does not work.
To display rulers for the page again, you must close / reopen mozilla developer tool and click on the Toggle rulers for the page icon.

Expected results:

The dimensions of the page should be displayed after refreshing the page, as it did under previous versions of Firefox 71.

Comment 1

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

Thanks for the details. I was able to reproduce the bug on Windows 10 on the following versions:

Release 71.0 (64-bit), and Nightly 73.0a1 (2019-12-16) (64-bit)

I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Clara.

Comment 2

[spip931]

Hi,

Thanks for your feedback Clara. (I want to say) What now?
Will this bug be fixed in future versions of Firefox?
Best regards, Nicolas.

Comment 3

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi Nicolas,

I am not able to provide an estimated date in which the bug will be fixed as it depends on the severity of the bug. Now we just need to wait for an answer from the dev that will take over this issue.

Have a great day!

Clara

Comment 4

[Brad Werth [:bradwerth]]

I'll find a regression window.

Comment 5

[Brad Werth [:bradwerth]]

Gabe, this was regressed by the changes in Bug 1500142. Would you please take a look?

Comment 6

[Gabriel Luong [:gl] (ΦωΦ)]

(In reply to Brad Werth [:bradwerth] from comment #5)

Gabe, this was regressed by the changes in Bug 1500142. Would you please take a look?

Sorry, someone else on devtools need to look at this since I am busy with Fenix.

Comment 7

[(Out Sep 17-23) Ryan VanderMeulen]

Hi Patrick, can you please help find an assignee for this regression? Thanks!

Comment 8

[Patrick Brosset <:pbro>]

Attachment: Bug 1602783 - Retrieve the right inspector front when updating the state of toolbar buttons

When a page navigation happens, we update the state of the toolbox toolbar buttons as some
of them need to disable themselves then (rulers and measurement tool).

In bug 1500142 the logic to do this was changed to retrieve the right inspector front
instead of always the top-level one, stored at toolbox level.
This is good. However the way this was done is by using the target.getCachedFront sync
method which, in this case, returns null. Because it returns null, that prevents the
rest of the button update logic to run, hence the bug.

Using the async target.getFront method instead fixes the bug.

I am not sure why this getCachedFront method does not work and why it was introduced
here. Sending this to phabricator so we can discuss with people who know more than me
about this.

Comment 9

[Patrick Brosset <:pbro>]

Julian found the problem, turns out the call to getCachedFront was simply wrong. See https://searchfox.org/mozilla-central/search?q=getCachedFront(%22inspector&case=false&regexp=false&path=
It should be getCachedFront("inspector") not getCachedFront("inspectorFront")).
So this was just an oversight that can be simply corrected.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:pbro, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/414e29381f04
Retrieve the right inspector front when updating the state of toolbar buttons r=jdescottes

Comment 12

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/414e29381f04

Comment 13

[(Out Sep 17-23) Ryan VanderMeulen]

Please nominate this for Beta approval when you get a chance.

Comment 14

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: rulers.webm

Hi, I tried to verify the fix in last nightly version ( 74.0a1 (2020-01-07) (64-bit)) but the issue is still ocurring (I restarted my computer just in case). Please see attachment for more details. Best,
Clara.

Comment 15

[(Out Sep 17-23) Ryan VanderMeulen]

This landed on m-c ~6hr after that build was created and there hasn't been another Nightly build since. Please check again with a newer build.

Comment 16

[Patrick Brosset <:pbro>]

Comment on attachment 9117267 [details]
Bug 1602783 - Retrieve the right inspector front when updating the state of toolbar buttons

Beta/Release Uplift Approval Request

• User impact if declined: If declined, using the rulers tool in DevTools will be confusing to people. The active status won't be correct after a page refresh, and they won't be able to use the rulers anymore.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is just fixing an obvious typo, and only concerns a seldom used tool inside of DevTools, and only after refresh of a page. This can also be recovered by restarting DevTools. So really low risk.
• String changes made/needed:

Comment 17

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi, I just checked the last nightly build and I was able to verify the fix, the rulers are now showing up correctly after refreshing browser (button gets disabled, but when clicking on it the rulers wll be displayed)
Thanks, I've updated the flags for 74.0a1 (2020-01-08) (64-bit) version.
Best,
Clara.

Comment 18

[(Out Sep 17-23) Ryan VanderMeulen]

Comment on attachment 9117267 [details]
Bug 1602783 - Retrieve the right inspector front when updating the state of toolbar buttons

Approved for 73.0b3.

Comment 19

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f41c75e0224c

Comment 20

[Clara Guerrero ( Need Info Brindusa Tot Please)]

I just verified the fix in Windows 10 pro, for FF Beta v73.0b3 (64-bit) build ID 20200108211453, I will update the flag to verified.

I can also confirm that I was able to reproduce this issue in FF Release v720 in Ubuntu 18.04.3 LTS , and this was fixed in 73.0b3 (64-bit) build ID 20200108211453

Best,
Clara

Comment 21

[spip931]

Hi,

Thank you all for resolving this bug for the latest version of FireFox.

However, one last little bug persists.

When you activate the rulers for the page, the rulers for the page appear (with, at the top right of the window, the dimensions in pixels) (so far so good and the behavior is logical).
Where the bug occurs is when we deactivate the rulers for the page. Indeed, at that time the rulers for the page disappear (it's logical) but NOT the dimensions (at the top right of the window) which are still displayed with the last dimensions.
When we re-activate the rulers for the page and when we change size of page, the dimensions change too.
Here's what I could say about this other little bug.

Otherwise, once again thank you for solving this (initial) bug.
Have a nice day ;)
Best,

Nicolas

Comment 22

[Patrick Brosset <:pbro>]

Thank you for finding this out. I opened bug 1608764 to get this fixed.