Closed Bug 804499 Opened 12 years ago Closed 8 years ago

Pressing the Enter key on the keyboard does not submit credentials form

Categories

(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect, P3)

ARM
Gonk (Firefox OS)

Tracking

(blocking-basecamp:-, feature-b2g:3.0?)

RESOLVED WONTFIX
blocking-basecamp -
feature-b2g 3.0?

People

(Reporter: gkw, Unassigned)

References

Details

(Keywords: b2g-testdriver, polish, unagi, Whiteboard: UX-P3, ux-tracking, [good first bug], 2.6UXnom)

Go to https://tbpl.mozilla.org/?noignore=1&jobname=valgrind and click on any build. Then click Rebuild. The Username and Password fields show up. Fill in the correct parameters. Press the enter key on the keyboard at the bottom right (it is initially bolded indicating it is pressable). Nothing happens. It should submit the form. Workaround: Clicking the Sign-in button at the top right works, though. === My Git commit info currently shows: 2012-10-17 12:16:24 e3efbd0411218762cf9a62278bf58ee513ff331f Also, seeing my comments in https://b2gtestdrivers.allizom.org/comments_table - my build ID currently is: 20121018092134
OS: Mac OS X → Gonk (Firefox OS)
Ben, is this a browser bug or a keyboard bug?
blocking-basecamp: --- → ?
(In reply to Jonas Sicking (:sicking) from comment #1) > Ben, is this a browser bug or a keyboard bug? I don't know what do you meant by "click on any build. Then click Rebuild". I am not familiar with tbpl. We cannot submit a <input> without a <form> and a action. This bug will be RESOLVED INVALID if you are talking about an <input> on the website. However, if the login is a HTTP auth login dialog, it's a browser bug since the dialog lives in the browser app.
Flags: needinfo?(gary)
1. Go to https://tbpl.mozilla.org/ 2. Click on any letter, e.g. a B. 3. At the bottom, there is a blue "+" icon. 4. If your credentials have not been entered, there will be a popup asking for username and password. (note: this is in production, so please do not authenticate and trigger too many rebuilds.)
Flags: needinfo?(gary)
I can't figure out how to reproduce this as described, but I tried a different HTTP authenticated site and couldn't submit the form with the enter button so I'm going to assume it is in fact the HTTP authentication dialog you're talking about. That makes this a browser bug, the HTTP auth dialog needs to listen for submit events.
Component: Gaia → Gaia::Browser
Per triage: while not optimal, this is a relatively minor usability issue, and HTTP auth is not a very common interaction. It's probably a simple fix, but we would not hold the release on this bug.
blocking-basecamp: ? → -
Keywords: polish
Hardware: x86 → ARM
Component: Gaia::Browser → Gaia::Keyboard
Priority: -- → P3
Whiteboard: UX_QA, interaction
Keywords: polish
Whiteboard: UX_QA, interaction → interaction, UX-P3
Case in point: setting up a gmail account.
Not sure why this got moved back to Gaia keyboard component. But if this issue is about HTTP auth dialog as comment 2 and 4 mentioned, this should live in the browser component. -- I still could reproduce this issue with today's build on master, when trying to access the following site, https://pvtbuilds.mozilla.org/ Build info =========== Gaia 002cca258af8586859c6efb2dada2fcec36754a1 Gecko http://hg.mozilla.org/mozilla-central/rev/34dddf6f7ec1 BuildID 20140114040616 Version 29.0a1 ro.build.version.incremental=eng.archermind.20131114.105818 ro.build.date=Thu Nov 14 10:58:33 CST 2013
Component: Gaia::Keyboard → Gaia::Browser
Whiteboard: interaction, UX-P3 → interaction, UX-P3, 2x-uxnom
Whiteboard: interaction, UX-P3, 2x-uxnom → interaction, UX-P3, 2x-uxnom, polish
Keywords: polish
Whiteboard: interaction, UX-P3, 2x-uxnom, polish → interaction, UX-P3, 2x-uxnom
Hey Ben - if this is a browser bug, does it still reproduce? If so, who would be able to fix it? Should it be considered for the "first bug" list? Thanks!
Flags: needinfo?(bfrancis)
There is no longer a browser app and we are talking about System browser I guess. I tried https://phonebook.mozilla.org/ and it still reproduces. The fix will be pretty similar to bug 1168600, which the form is responsible to catch the submission caused by the enter key, either with the click event on the submit button (<button> or <input type=submit>) or the submit event on the <form>.
feature-b2g: --- → 3.0?
Component: Gaia::Browser → Gaia::System::Browser Chrome
I think Tim's right, the HTTP dialog needs to catch the submit event. Yes this would be a good first bug, how do we mark those?
Flags: needinfo?(bfrancis)
I can't remember the exact phrasing for the whiteboard field but I know Naoki knows.
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(nhirata.bugzilla)
Whiteboard: interaction, UX-P3, 2x-uxnom → interaction, UX-P3, 2x-uxnom, "good first bug"
Whiteboard: interaction, UX-P3, 2x-uxnom, "good first bug" → interaction, UX-P3, 2x-uxnom, [good first bug]
Whiteboard: interaction, UX-P3, 2x-uxnom, [good first bug] → UX-P3, ux-tracking, [good first bug], 2.6UXnom
See Also: → 1240923
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.