Closed
Bug 781318
Opened 13 years ago
Closed 12 years ago
HTTP auth prompt doesn't show keyboard
Categories
(Firefox for Android Graveyard :: Keyboards and IME, defect)
Tracking
(firefox14 affected, firefox15 affected, firefox16 affected, firefox17 affected, firefox19 verified)
VERIFIED
FIXED
Firefox 18
People
(Reporter: keeler, Assigned: wesj)
Details
(Whiteboard: VKB)
Attachments
(1 file)
6.20 KB,
patch
|
mbrubeck
:
review+
|
Details | Diff | Splinter Review |
When prompted for HTTP authentication (on, e.g. intranet.mozilla.org), Firefox for Android doesn't bring up the on-screen keyboard until I tap an input field. This is on an HTC One X with ICS 4.0.3.
Comment 1•13 years ago
|
||
We have gone back and forth on this kinda of issue. Opening the keyboard reduces screen space. On the other hand, making the user tap is one more tap.
Personally, I like it the way we currently have it, but I'll loop UX in to comment.
Keywords: uiwanted
Comment 2•13 years ago
|
||
Commit pushed to master at https://github.com/mozilla/socorro
https://github.com/mozilla/socorro/commit/d3ce7093a1b400b19f0cef7b2a45adf1fc181baa
Merge pull request #781 from bsmedberg/master
bug 781318 - Fix the append/skiplist for "WaitFor" and "BaseGetNamedObjectDirectory" signatures on hangs
![]() |
Reporter | |
Comment 3•13 years ago
|
||
I understand that screen real-estate is precious on phones, but when that prompt comes up and you're not using the password manager, what else are you going to do but input text?
Either way, the reason I thought this was a bug at all was that the editing cursor was blinking in the username field, which indicated to me that the device thought I was ready to input text, which I was not, given that the keyboard wasn't up.
Comment 4•13 years ago
|
||
This behavior is pretty annoying (and confusing because the cursor is blinking in the username field).
I don't think saving screen real estate is a valid reason because this is a modal native dialog, not part of the web page. Both Chrome and ICS stock browser open the VKB.
status-firefox14:
--- → affected
status-firefox15:
--- → affected
status-firefox16:
--- → affected
status-firefox17:
--- → affected
Whiteboard: VKB
Comment 5•13 years ago
|
||
I can see both sides here, but I think generally I am leaning toward showing the keyboard. Partly to save an extra tap, partly because as Chris mentioned, it seems odd that the cursor blinks but no keyboard appears right now.
While I agree with Mark that leaving the keyboard closed affords us more space, and generally makes it a little easier to digest what is happening on screen, that might not purely be a result of whether the keyboard is present or not. For one thing, we could probably do a bit of tuning to our dialog styling -- when you compare ours to stock browser or chome, we look a little unpolished by comparison.
Happy to open a separate "give our dialogs a bit of UI love" bug about that, though.
Assignee | ||
Comment 6•13 years ago
|
||
Assignee: nobody → wjohnston
Attachment #651483 -
Flags: review?(mbrubeck)
Comment 7•13 years ago
|
||
(In reply to Wesley Johnston (:wesj) from comment #6)
> Created attachment 651483 [details] [diff] [review]
> Patch
remember to remove the debugging Log calls
Comment 8•13 years ago
|
||
Comment on attachment 651483 [details] [diff] [review]
Patch
Review of attachment 651483 [details] [diff] [review]:
-----------------------------------------------------------------
r=mbrubeck with minor nits addressed
::: mobile/android/base/PromptService.java
@@ +83,5 @@
> private class PromptInput {
> private String label = "";
> private String type = "";
> private String hint = "";
> + public Boolean autofocus = false;
Why "public"?
@@ +140,5 @@
> + Log.i(LOGTAG, "xxx - Request focus 2 " + hasFocus);
> + }
> + }
> + });
> + Log.i(LOGTAG, "xxx - Request focus");
Remember to remove the debug logging.
Attachment #651483 -
Flags: review?(mbrubeck) → review+
Assignee | ||
Comment 9•13 years ago
|
||
Comment 10•13 years ago
|
||
This appears to have turned bug 651866 permaorange.
Comment 11•13 years ago
|
||
(In reply to Ed Morley [:edmorley] from comment #10)
> This appears to have turned bug 651866 permaorange.
That's totally bizarre, since I don't think this code should be running during reftests at all. I wonder what they are doing that calls the prompt service.
Backed out for now:
https://hg.mozilla.org/integration/mozilla-inbound/rev/12d306fa30d5
Keywords: uiwanted
Assignee | ||
Comment 12•12 years ago
|
||
This test was disabled for being all around faulty. This looked fine on try, so I relanded it.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac4d3cec62a1
Comment 13•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
Updated•12 years ago
|
Status: RESOLVED → VERIFIED
status-firefox19:
--- → verified
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
•