1418377 - Tooltip for developer toolbar button does not display shortcut when in private browsing (displays "%S" instead)

Status: RESOLVED WORKSFORME

(DevTools :: General, defect, P3)

Description

[Patrick]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171115114231

Steps to reproduce:

Hover over a menu item that has a tooltip whilst in incognito mode.


Actual results:

Tooltip displays (%s) instead of the shortcut


Expected results:

(%s) should display the shortcut available

Comment 1

[Josh Matthews [:jdm]]

Could you be more specific about what menu item you are referring to?

Comment 2

[Patrick]

This is with Firefox Developer if that isn't already clear. One of the items was Developer tools where it appears right of the address bar.

Comment 3

[Josh Matthews [:jdm]]

I can reproduce this in both developer edition and nightly. It only happens with the "Open Web developer tools" item for me; Reload and Downloads show the keyboard shortcut just fine.

Comment 4

[Josh Matthews [:jdm]]

I cannot reproduce this in FF 57.

Comment 5

[Gerry Chang [:gchang]]

Track 58+ as new regression. 
Hi Josh,
Will you work on this?

Comment 6

[Josh Matthews [:jdm]]

It makes more sense for someone with FF UI experience to investigate this problem.

Comment 7

[:Gijs (he/him)]

(In reply to Josh Matthews [:jdm] from comment #4)
> I cannot reproduce this in FF 57.

Uh, that's odd, I see this in 56. STR:

./mach mozregression --launch 2017-08-01

1. open customize mode
2. drag developer button to the toolbar
3. hit accel-shift-p to open a private window
4. hover over button.

Not convinced this is a recent regression, if it's a regression at all. Can you recheck? Am I doing something wrong?

Alexandre: is this perhaps something to do with devtools-as-an-addon or something?

Comment 8

[:Gijs (he/him)]

With the STR from comment #7, I even see this on 51 (2016-08-01).

Comment 9

[Josh Matthews [:jdm]]

Yeah, I definitely see it in FF 57 when trying again. Not sure what happened previously.

Comment 10

[:Gijs (he/him)]

(In reply to Gerry Chang [:gchang] from comment #5)
> Track 58+ as new regression. 

Given that this affects 51 and therefore ESR (see last few comments), I'm clearing tracking. Gerry, let me know if that's problematic.

Comment 11

[Cosmin Muntean [:cmuntean], Ecosystem QA]

This issue is also reproducible when you open a new window (Ctrl + N). 
I have found an old Nightly (48.0a1, 2016-03-15) build where the issue is not reproducible. 

Considering this I have performed a regression using mozregression tools. Here are the results:
Last good revision: 538d248fa252a4100082fd9bc3fdc08d322cda22 (2016-04-01)
First bad revision: c40c0b2f3b4c778af4307e090b4063b63c806cda (2016-04-02)
Pushlog: https://goo.gl/naXAzh
I have tried to go further but I have received this error: "There are no build artifacts on inbound for these changesets (they are probably too old).".

Comment 12

[Gerry Chang [:gchang]]

:Gijs,
No problem. It's not a new regression in 58. It makes sense to un-track 58.

Comment 13

[Patrick Brosset <:pbro>]

Confirmed that this happens on all new windows, not just private ones.
Definitely seems related to bug 1248603, so the needinfo for Alex makes sense.

Comment 14

[Patrick Brosset <:pbro>]

Tested again on devedition and nightly (64 and 65) and can't reproduce the issue anymore. So I'm closing this one for now. Feel free to re-open.