Closed
Bug 912306
Opened 11 years ago
Closed 9 years ago
Form history dropdown reappears after moving focus outside the associated form field
Categories
(Firefox for Android Graveyard :: General, defect, P5)
Tracking
(firefox24 affected, firefox25 affected, firefox26 affected, relnote-firefox -, fennec+)
People
(Reporter: MattN, Unassigned, Mentored)
Details
(Keywords: regression, Whiteboard: [lang=java][lang=js][bad first bug])
Attachments
(1 file)
134.10 KB,
image/png
|
Details |
STR:
1) Load a page with a form where there are form history entries. (e.g. https://mail.mozilla.com )
2) Type some letters from a previous entry.
3) Choose an entry from the dropdown
4) Hit tab on the keyboard or tap outside the form
Expected result:
Form history dropdown closes
Actual result:
Form history dropdown reopens on the same field
Comment 1•11 years ago
|
||
Do you know if this is a recent regression?
Keywords: regressionwindow-wanted
Reporter | ||
Comment 2•11 years ago
|
||
I think it was within the last few weeks but I'm not sure.
Comment 3•11 years ago
|
||
(In reply to Matthew N. [:MattN] from comment #2)
> I think it was within the last few weeks but I'm not sure.
So it doesn't happen on Aurora?
Updated•11 years ago
|
tracking-fennec: --- → ?
Comment 4•11 years ago
|
||
The regression window is:
mozilla-central
good build: 19.06.2013
bad build: 20.06.2013
-pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d2a7cfa34154&tochange=8ea92aeab783
Updated•11 years ago
|
Assignee: nobody → margaret.leibovic
tracking-fennec: ? → 24+
Updated•11 years ago
|
Keywords: regressionwindow-wanted
Comment 5•11 years ago
|
||
Regression from bug 877782? Is this still tracking 24?
Updated•11 years ago
|
Status: NEW → ASSIGNED
Comment 6•11 years ago
|
||
Issue is reproducible on Firefox Mobile 24 beta 10 on Asus Transformer (Android 4.0.3 )
status-firefox24:
--- → affected
status-firefox25:
--- → affected
Updated•11 years ago
|
relnote-firefox:
--- → ?
Comment 7•11 years ago
|
||
I'm having a hard time reproducing this issue as described, although I am seeing us get into a weird state if I dismiss/reopen the keyboard. It seems very similar to bug 895463, so I'm cc'ing capella in case he wants to investigate (it seems like we should file a separate bug for that, though).
Matt, what device were you using? Could this be an issue with a hardware keyboard? On my phone, when the username field is focused on http://mail.mozilla.com, I only have a "Go" button available, not a "Next". Tapping outside the input element always removes focus from the input, which always hides the autocomplete popup for me. Also, tapping on a suggestion always hides the popup as well.
I'm testing on a Nexus 4.
relnote-firefox:
? → ---
Comment 8•11 years ago
|
||
Oops, accidentally reset the relnote-firefox flag.
relnote-firefox:
--- → ?
Reporter | ||
Comment 9•11 years ago
|
||
(In reply to :Margaret Leibovic from comment #7)
> Matt, what device were you using? Could this be an issue with a hardware
> keyboard?
I was using an ASUS Transformer TF101 with both Asus and Google soft keyboards (I don't have the hardware keyboard).
I would guess it has something to do with the keyboard closing which adjusts the viewport. I think we are trying to reposition the dropdown for the new viewport size when the keyboard closes after focus leaves the input. It seems like a race between those events.
Reporter | ||
Comment 10•11 years ago
|
||
i.e. I think we are adjusting the position of the dropdown when it is closed or closing which causes it to re-appear.
Updated•11 years ago
|
tracking-fennec: 24+ → ?
Updated•11 years ago
|
tracking-fennec: ? → +
Comment 11•11 years ago
|
||
bug 895463 may indeed be related to the same basic issue ... both the TextSelection caret and the dropdown dialog float in the wrong place ... (see attached)
fyi in bug 895463 comment 14 I posted a brief fiddle test where I observe the caret scroll downscreen during element loss of focus and softKbd close, implying a relationship to the caret position and the top of the kbd / bottom of (?)
mattn above in comment 10 mentions |i.e. I think we are adjusting the position of the dropdown when it is closed or closing| ...
I don't know how that works for dropdown, but for TextSelection caret we adjust position by exchanging messages between SelectionHandler.js and TextSelection.java ...
This is not observed occuring during the caret-move-to-wrong-position scenario in my testing.
Comment 12•11 years ago
|
||
Since this is not easy to reproduce, and we can't tie it to a specific device or set of steps, I don't think it's necessary to relnote
Comment 13•11 years ago
|
||
I haven't had time to work on this. I'm going to make this into a mentor bug, but fixing it will involve figuring out a reliable way to reproduce it and digging into the form autocomplete code, so I'd recommend only a more experienced contributor try to work on this.
Assignee: margaret.leibovic → nobody
Whiteboard: [mentor=margaret][lang=java][lang=js][bad first bug]
Assignee | ||
Updated•11 years ago
|
Mentor: margaret.leibovic
Whiteboard: [mentor=margaret][lang=java][lang=js][bad first bug] → [lang=java][lang=js][bad first bug]
Updated•9 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•