Chris Peterson [:cpeterson] Reporter
	Description • 12 years ago

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.

	Walter Chen[:ypwalter][:wachen]
	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.

	Matt Basta [:basta]
	Comment 2 • 12 years ago

I second this feature. Commas are completely un-useful while typing URLs.

	David Flanagan [:djf]
	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).

	David Flanagan [:djf]
	Comment 4 • 12 years ago

Cc'ing Josh too, to get UX input.

	Rudy Lu [:rudyl] (inactive after 2015/7/3)
	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.

	Dietrich Ayala (:dietrich)
	Comment 6 • 12 years ago

Yes please, but not bad enough to block the whole release.

	Ben Francis [:benfrancis]
	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.

	Matt Basta [:basta]
	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.

	Ben Francis [:benfrancis]
	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

	Matt Basta [:basta]
	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.

	Rudy Lu [:rudyl] (inactive after 2015/7/3)
	Comment 11 • 11 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.

	Ben Francis [:benfrancis]
	Comment 12 • 11 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.

	Matt Basta [:basta]
	Comment 13 • 11 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" />

	Ben Francis [:benfrancis]
	Comment 14 • 11 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".

	Mounir Lamouri (: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.

	Ben Francis [:benfrancis]
	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?

	Matt Basta [:basta]
	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.

	Naoki Hirata :nhirata (please use needinfo instead of cc)
	Comment 18 • 11 years ago

What type of keyboard should we have for the Rocketbar?

	Rudy Lu [:rudyl] (inactive after 2015/7/3)
	Comment 21 • 10 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.

	Rudy Lu [:rudyl] (inactive after 2015/7/3)
	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.