Closed
Bug 821835
Opened 12 years ago
Closed 10 years ago
The keyboard for Browser App. Awesome Bar should replace ',' key with '/'
Categories
(Firefox OS Graveyard :: Gaia::Keyboard, defect)
Tracking
(b2g18+)
RESOLVED
INVALID
Tracking | Status | |
---|---|---|
b2g18 | + | --- |
People
(Reporter: cpeterson, Unassigned)
References
Details
When entering a URL or search in the B2G browser's address bar, the default keyboard layout has no '/' key. It has a ',' key which is not commonly needed for entering URLs or search queries.
Comment 1•12 years ago
|
||
Not sure if this should be done now. But, according to user story, there should be another type of keyboard coming out soon in next version or someday. (I think it was called "awesomebar keyboard" or something.
It's a good to have with .com key implemented.
Hardware: All → ARM
Comment 2•12 years ago
|
||
I second this feature. Commas are completely un-useful while typing URLs.
Comment 3•12 years ago
|
||
Why hasn't this been a big complaint from dogfooders? Nominating it for leo to get it on people's radar. Also cc'ing Ben. The fix would be trivial, I think. Can we do this?
Note that if anyone needs a comma in a url, they can press and hold the . key to get a comma (or other punctuation).
blocking-b2g: --- → leo?
Comment 4•12 years ago
|
||
Cc'ing Josh too, to get UX input.
Comment 5•12 years ago
|
||
Hi all,
Since Bug 797867, we changed the input type of awesome bar from "url" to "text" so that we could enter [whitespace] when using the search feature.
Change the summary to reflect the real situation.
See Also: → 817904
Summary: B2G keyboard layout should replace ',' key with '/' when input type="url" → The keyboard for Browser App. Awesome Bar should replace ',' key with '/'
Comment 6•12 years ago
|
||
Yes please, but not bad enough to block the whole release.
blocking-b2g: leo? → -
tracking-b2g18:
--- → +
Comment 7•12 years ago
|
||
The browser uses the type=text keyboard, not the type=url keyboard. As Rudy said this is so that there is a space button for searches. Neither the default URL keyboard or default search keyboard are appropriate for the hybrid case of the awesomebar which is why the generic text keyboard is used.
Replacing , with / on this keyboard would do so everywhere type=text is used.
Comment 8•12 years ago
|
||
(In reply to Ben Francis [:benfrancis] from comment #7)
> Replacing , with / on this keyboard would do so everywhere type=text is used.
That's obviously not the solution, then.
Why can't the browser use type="search" and we put the slash on the search keyboard? It's conceivable that more searches have slashes than commas. The other (less ideal but still viable) option is to use something like type="moz-awesomebar" and have a custom keyboard layout just for that.
Comment 9•12 years ago
|
||
(In reply to Matt Basta [:basta] from comment #8)
> Why can't the browser use type="search" and we put the slash on the search
> keyboard? It's conceivable that more searches have slashes than commas. The
> other (less ideal but still viable) option is to use something like
> type="moz-awesomebar" and have a custom keyboard layout just for that.
Déjà vu https://github.com/mozilla-b2g/gaia/issues/3566
Comment 10•12 years ago
|
||
It seems like that issue raises a few points:
1. The URL keyboard has no space, making it bad for searching
2. The text keyboard has no forward slash, making it bad for URLs
3. We could create our own input type, but that's bad for standards
4. We could keep the wrong keyboard type, but that's bad for users
I think most of the points in that github issue are very relevant but I also think that the current experience is simply unsatisfactory and could be remedied simply by sticking a single key on the type="URL" keyboard.
The original Keyboard Recommendations doc linked from that issue (https://wiki.mozilla.org/images/2/20/Keyboard_Specs.pdf) includes forward slash, space, hyphen, colon, and TLD keys on the URL keyboard (slide 11). The updated spec (linked from dropbox) no longer exists, so I can't speak to that.
I agree with Rafael's note about web standards, which just about sums up my thoughts:
> I think that if "we can't currently do with web standards" then we -the proverbial collective we- need new, better standards :)
Some notes:
- Android's URI keyboard (inputType:textUri) has both a space and a forward slash.
- The iOS address bar (at least in older versions of iOS, not sure about recent versions) doesn't have a space and isn't built for searching.
Comment 11•12 years ago
|
||
I am tempted to think that we should provide a way to solve this UX issue, even it is kind-f hacky.
I would like to propose using "x-inputmode=moz-awesomebar", so that we can let Gaia keyboard know this is a special case of URL keyboard that needs both URL related features and also a space key.
Comment 12•12 years ago
|
||
(In reply to Rudy Lu [:rudyl] from comment #11)
> I would like to propose using "x-inputmode=moz-awesomebar", so that we can
> let Gaia keyboard know this is a special case of URL keyboard that needs
> both URL related features and also a space key.
This has been suggested before on multiple occasions and I strongly disagree with this approach. If there's a missing input mode in the web standard we should propose a new one, not add a special hack for Firefox OS.
Comment 13•12 years ago
|
||
(In reply to Ben Francis [:benfrancis] from comment #12)
> This has been suggested before on multiple occasions and I strongly disagree
> with this approach. If there's a missing input mode in the web standard we
> should propose a new one, not add a special hack for Firefox OS.
What are the appropriate channels to propose an amendment to the standard, or at least start a conversation with the standards guys? I can imagine many cases where this is useful.
Perhaps as an alternative to a proprietary attribute, we could propose something like: <input type="url,search" />
Comment 14•12 years ago
|
||
(In reply to Matt Basta [:basta] from comment #13)
> What are the appropriate channels to propose an amendment to the standard,
> or at least start a conversation with the standards guys? I can imagine many
> cases where this is useful.
>
> Perhaps as an alternative to a proprietary attribute, we could propose
> something like: <input type="url,search" />
I'm not sure, Mounir?
This sounds like a better approach than "x-inputmode=moz-awesomebar".
Flags: needinfo?(mounir)
Comment 15•11 years ago
|
||
I would be against both of those ideas because they touch the web, not only the Firefox OS world. However, if I had to decide between the two, I would prefer to add a proprietary addition to inputmode but this would be a pure hack because I doubt this will be added to the specification for the years to come.
Flags: needinfo?(mounir)
Comment 16•11 years ago
|
||
(In reply to Mounir Lamouri (:mounir) from comment #15)
> I would be against both of those ideas because they touch the web, not only
> the Firefox OS world.
Huh? The Firefox OS world *is* the web. Anywhere that it isn't is a bug.
> However, if I had to decide between the two, I would
> prefer to add a proprietary addition to inputmode but this would be a pure
> hack because I doubt this will be added to the specification for the years
> to come.
So you're advocating a Firefox OS specific hack? I'm very surprised to hear this from you. Is it because you think this use case is unique to Firefox OS and not applicable to the web in general?
If someone created a third party app which needed a hybrid search and URL input field, should they use a proprietary hack for each user agent? Should webkit create a x-inputmode=webkit-awesomebar too?
Or is it the user interface design that is at fault and you should never have a hybrid search and URL input?
Comment 17•11 years ago
|
||
I think it's not debated that if there's a genuine use case for this that exists beyond a one-off for Firefox OS, we should work to take whatever we do and make it a standard.
What type of keyboard should we have for the Rocketbar?
blocking-b2g: - → ---
Flags: needinfo?(jcarpenter)
Comment 21•11 years ago
|
||
I have a new proposal and have posted it to dev-webapi,
https://groups.google.com/d/msg/mozilla.dev.webapi/CrBU2Vwpi2M/DL_rXNlr1ykJ
Please feel free to discuss this issue on the mailing list.
Thanks.
Comment 22•10 years ago
|
||
With bug 1038726 (for system browser) and bug 1035619 (keyboard app), we already switched to type=search for the awesomebar, so I think this is no longer a valid issue.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(jcarpenter)
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•