arni2033 Reporter
	Description • 8 years ago

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Open url   data:text/html,<textarea>goargeous bugs</textarea>
2. Press Tab key to focus textarea, make sure that caret is placed in the beginning of textarea
3. Press Shift+F10 to open context menu
4. Press Down key to select 1st menuitem

AR:  Window's context menu opens (the same context menu that opens on Alt+Spacebar)
ER:  Browser should just switch to 1st menuitem. No irrelevant menus please.

This is regression from bug 1072150. Regression range:
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6457f01e4bcb818060f89c3b80ae0596e1583345&tochange=6256ec9113c115141aab089c45ee69438884b680@ Bobby Holley (PTO) (busy with Stylo):
It seems that this is a regresion caused by your change. Please have a look.

	Mats Palmgren (inactive)
	Comment 1 • 8 years ago

Alice, you're on Windows IIRC, can you confirm the regression range in comment 0?
It seems kind of unlikely that bug 1072150 caused this.
(The STR works fine on Linux, fwiw, so I suspect it's a Windows-only bug.)

	Alice0775 White
	Comment 2 • 8 years ago

> 2. Press Tab key to focus textarea, make sure that caret is placed in the beginning of textarea

After doing "Press Tab key to focus textarea", the caret is goargeous bugs[|] (i.e. at the end of texts).

How is the caret placed in the beginning of textarea?

	Mats Palmgren (inactive)
	Comment 3 • 8 years ago

I don't think that part of STR is important, you can just move the caret to the start
by any means.  The important part (I guess) is that it's next to the misspelled word
so that a suggested corrected word comes up in the context menu.

	Alice0775 White
	Comment 4 • 8 years ago

It is very difficult to reproduce the problem. The probability is less than 1/20 in my case.

At least, I can reproduce the problem on the good build[1] with e10s.
So, the regression range of comment#0 is not correct.

[1]
https://hg.mozilla.org/mozilla-central/rev/6457f01e4bcb818060f89c3b80ae0596e1583345
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 ID:20150926034134

	Mats Palmgren (inactive)
	Comment 5 • 8 years ago

Thanks.  I suspect DOM probably isn't the right component for this bug then.
"XPToolkit Menus" or "Keyboard Navigation" perhaps?

	castiel743
	Comment 6 • 8 years ago

I have tested it on the reported version and on "latest" Nightly, and I must notice, the difference is important. STR_1 is reproducible almost every times on reported version, but not on "latest" Nightly, where it's almost not reproducible. I'm not sure whether this change is worth investigating.
Also, on reported vesion caret appears in the beginning of <textarea>, and on the "latest" Nightly it appears in the end, which explains comment 2.

I personally think that those aspects are important, for example when <textarea> becomes focused, caret should be placed within an incorrect word (underlined with red). Also, I assumed that it's best to have a long wrong word to reproduce this bug reliably.
As a result, I reproduced the bug in 9/10 cases on latest Nightly with STR_2.

STR_2:
1. Open url   data:text/html,<textarea>goargeousssssssssssss</textarea>
2. Press Tab to focus textarea, make sure that caret is placed in the end of textarea
3. Press Shift+F10 to open context menu
4. Press Up key to select the last menuitem

AR:  Window's context menu opens (the same context menu that opens on Alt+Spacebar)
ER:  Browser should just switch to 1st menuitem. No irrelevant menus please.

Further notes:
I sometimes encounter this bug on a random web pages, which explains comment 4. It happens unpredictably and I don't know reliable STR. But this testcase somehow makes it more reproducible (I think it's the same bug). I assume that there must be something in bug 1072150 that made this bug more reproducible for the reporter, but I'm not sure whether it's worth investigating.