Open Bug 1667941 Opened 4 years ago Updated 3 years ago

Alt-2 to Alt-7 not working after updating to Firefox 78.3.0esr

Categories

(Core :: DOM: Core & HTML, defect, P3)

78 Branch
defect

Tracking

()

Tracking Status
firefox-esr78 --- affected

People

(Reporter: sven_y_joensson, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

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

Steps to reproduce:

On a the site https://app.arkivdigital.se I could with previous ESR-version use Alt-1 to Alt-9 (except Alt-8 which is not used) to copy text strings from the web application.
After updating to latest ESR-version Alt-2 to Alt-7 is not working, but Alt-1 and Alt-9 and Alt-0 works as in previous version.
Verified problem in both 32-bit and 64-bit Firefox.
The site is a subscription service, so you can't text it there.

Actual results:

Nothing happens

Expected results:

text string from web-application copied so I can past in other application.

Sven, were you upgrading from the older ESR 68 or from ESR 78.2?

Flags: needinfo?(sven_y_joensson)

Hi Pascal, I upgraded from previous ESR-version, which I think was 78.1.

Flags: needinfo?(sven_y_joensson)

Sorry, the version probably was 78.2.

Mike, FYI this is an ESR regression in 78.3.

UPDATE: If I click on one of the frames in the web-page (a text frame in some pages, an image on others) the Alt-number works as with previous version!
It seams that the new version have changed behavior and set focus in another frame?

As far as you know, are you using any enterprise policy to enable this? Particularly:

ui.key.menuAccessKeyFocuses

I'm just a user, but I can contact the support on arkivdigital.se.
Is there any know problem with this function that I can ask them to forward to the developers?

So your machine doesn't have any policy applied by your company? Do you see anything when you go to about:policies?

Mike! about:policies shows: The Enterprise Policies service is inactive.

Ok, unrelated to policy so need to look at ESR checkins. Ryan, can you think of anything that went in between 78.1 and 78.3?

Flags: needinfo?(ryanvm)

Can you provide me with specific instructions as to where the Alt+X keys worked? I've created an account and I'm looking at demo data.

Thanks!

Never mind, I found it.

I'm not able to recreate the problem. Please let me know if I'm doing the right thing. For testing, I went to:

https://app.arkivdigital.se/register-collections/register-posts/r3.p5631853?query=1950&register_collection=3

Under copy, it shoes that I can use Alt+1 - alt+4 to copy various values. I verified that those keys worked problem in the first ESR and the latest ESR.

I clicked in different parts of the screen and made sure Alt always copied.

Can you point me to a page that uses Alt+1 through Alt+9? Hopefully it's available on the demo site.

Hi Mike, two id with text and image: r5.p182748856 v108240.b85.s80
Paste them in the Open box in the top of the page.
Normally I don't click on anything, just open a new source, and the Alt-2 to Alt-7 don't work. But test to click in the leftmost column whit archive information, that probably have focus when I open a new source. If I click anywhere else it works OK.

QA Whiteboard: [qa-regression-triage]

I can confirm and it is a regression.

The company gave me a 2 day account. I'm running through mozregression now.

Status: UNCONFIRMED → NEW
Ever confirmed: true

mozregression came back with

Bug 1661707 - Add ASRouter targeting for newtab and home page settings r=andreio

Differential Revision: https://phabricator.services.mozilla.com/D89027

which seems unlikely.

The regression definitely happened between 9/01 and 9/02 so that eliminates the bug Ryan mentioned. I'm doing more testing.

OK, so now I can't recreate, and I'm starting to understand things more (I think). I'm not sure we have a bug here.

So when you navigate to v108240.b85.s80, focus goes to the page and Alt+2 works for me. You see this because the cursor is not in the entry field.

When you navigate to r5.p182748856, focus is left in the entry field. So Alt+2 won't work until you click outside.

This behavior is consistent on Firefox back to 68 and would be specific to the web application.

Sven: Can you verify that the times when Alt+2 doesn't work, the cursor is in the entry field where you did the paste?

Flags: needinfo?(sven_y_joensson)

Mike: When I paste in the entry field and press Enter the cursor stays in the entry field, and Alt+2 does not work.
If I click Open instead of pressing Enter the Alt+2 do work, sorry I did give you misleading description!
Normally I open a new image by clicking on it's description in the leftmost column with source volumes, and then the Alt+2 do not work.

Flags: needinfo?(sven_y_joensson)

I'm sorry we're going back and forth on this. They've given me 3 more days of access, so I'm continuing to test.

Every time I think I have a scenario that recreates the problem, when I try to test again it starts working.

Here's what I've tried:

Login.
Clear everything out of the left sidebar (click X to remove everything).
Paste v108240.b85.s80 into the entry field and press enter.
Press Alt+2.
Verify that Ask (M) AI:9 (1866-1870) Image 85 / Page 80 is on the clipboard. (It's working).

Clear everything out of the left sidebar (click X to remove everything).
Paste r5.p182748856 into the entry field and press enter.
Note that the cursor is in the entry field so I know Alt+2 won't work.

I've randomly seen cases where Alt+2 doesn't work, but I can't come up with any consistent scenario.

Mike: Normally I have several application started and switch between them with Alt+Tab.

Could you test this:

  1. Open v108240.b85.s80
  2. Press Alt+Tab and switch to another application (Notepad or something else)
  3. Press Alt+Tab and switch back to Firefox
  4. Press Alt+2 and check if it is correct info

When I do this it always fails.
I should have tested more before I reported this bug, and gave you a lot of extra work! Sorry about that.

So the problem in your last comment is definitely a bug, but I don't think it's the one you first opened this bug for because that fix has been in the 78 ESR all along. I believe this bug is is the culprit:

https://bugzilla.mozilla.org/show_bug.cgi?id=1597857

Move execCommand("cut"/"copy") to new user activation model

If you could continue looking for a reproduction scenario of your first problem, that would be great unless you think this is the issue, and you saw it before 78.2

Edgar: Any thoughts on the scenario in https://bugzilla.mozilla.org/show_bug.cgi?id=1667941#c21? mozregression narrowed it down to:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e05793f68994829d3eb505f9f062faf5d8bb1016&tochange=a170089a8a033b5a2d8bba365656965aebe3a444

and your fix seems the only like one.

Flags: needinfo?(echen)

The problem described in comment 21 was what got me to report this bug. And in 78.2esr it did work fine.

Then I tried to get the problem without involving a second application and Alt+Tab, but as Mike found that way of working did sometime work and sometime not.
I think we concentrate on workflow in comment 21, that's my problem.

I see the bug on the 78.2.0esr which is why I am confused. There's definitely a bug here, I just don't understand why you're seeing different results on the ESR. I'll test some earlier ESR builds.

Side note, I can recreate this using the demo version of the website by using v100987.b1 (it has to be an image)

Hi,
as per comment 17 is it ok to remove regressionwindow-wanted from keywords and update "Has Regression Range" with yes? (NI? Mihai since Ryan nor Pascal are not accepting requests at the moment, sorry for the inconveniences)
Best regards,
Clara

Flags: needinfo?(mihai.boldan)

Agree Clara. Thanks for the heads up. It seems that the regression was mentioned above.
Removed the regressionwindow-wanted flag.

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(mihai.boldan)

(In reply to Mike Kaply [:mkaply] from comment #22)

Edgar: Any thoughts on the scenario in https://bugzilla.mozilla.org/show_bug.cgi?id=1667941#c21? mozregression narrowed it down to:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e05793f68994829d3eb505f9f062faf5d8bb1016&tochange=a170089a8a033b5a2d8bba365656965aebe3a444

and your fix seems the only like one.

I think it is because Alt + 2 isn't be considered as a user gesture, something it works presumably because there is another user gesture being triggered before, for example, mouse click.

Severity: -- → S3
Flags: needinfo?(echen)
Priority: -- → P3
Blocks: 1577516
See Also: → 1641171

Thanks Mihai, in case there's anything I can help with let me know.
Best,
Clara

Flags: needinfo?(mihai.boldan)
Flags: needinfo?(mihai.boldan)

Seems like this issue has been forgotten in untrained, let's fix that.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
You need to log in before you can comment on or make changes to this bug.