If your worry is PageUp/Down, why don't you exclude these keys from the
input field and let them bubble up? (Possibly only in the focus() case.)
Meaning: The focus is in a single-line text field, and the user presses
PageUp. What should happen? I would claim that it's reasonable to make
the page scroll.
If that's not the case right now, it might be as easy as avoiding adding
|if (key != pageUp ...) {| around event.preventDefault(); inside
<input>.onKeyPress(event).
Factors to consider when doing that:
* Single line text field or multi-line field (I would think that a
webpage-set focus() is much more likely to be actually important when
set inside a multi-line text field)
* Desktop vs. mobile version of site
* user set focus or page-set focus()
Just because some site are wrongly setting focus is not a good enough
reason to entirely break it. You'd also break those pages who use it
properly. Before making a move on this, make a statistic of how many
uses are appropriate and how many are not. Include normal websites (like
nytimes.com) and advanced webapps (like FogBugz).
Ben
Richard Z wrote on 05.06.2016 13:22:
On Thu, Jun 02, 2016 at 03:53:38PM -0700, Kevin Brosnan wrote:
Yes this has been discussed before.
https://bugzilla.mozilla.org/show_bug.cgi?id=717361 and
https://bugzilla.mozilla.org/show_bug.cgi?id=701741 for context. This
mailing list is a better place for discussion than the bugs.
It seems indeed that the behavior is worst when viewing desktop sites
on mobile where the keyboard popups at random.
But even desktop sites on desktop can make it a true disaster:
consider http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4884392/ , scroll
down a few pages by mouse wheel and hit PageUp/Down. In my version of
Firefox the PageUp/Down is caught by the single line searchbox on top
of the page and I loose my "reading point" - have to unfocus the search
box with the mouse and find my reading point many pages down again.
So even though the current focus() behavior which is "correct" in some
abstract sense there would be a bunch of problems like the above to be
fixed to make it actually usable in real life.
If .focus() is totally ignored or configurable to be ignored there would be
(1) many pages where the use has to explicitly focus input fields or text
areas
(2) some pages that supposedly break
Given that .focus() makes keyboard navigation completely unusable as
described above I don't think that (1) is a serious worry - if something
as trivial as PageDown in a page is seriously broken than (auto)focus
is the smaller problem.
Is (2) still a concern, is it fixable?
What is easier to fix - realworld usability of working .focus() or (2) ?
How did other browsers fix it on the desktop (if they did)?
As a middle way we could have an extension that would disable or whitelist
.focus() on certain pages. Certainly easiest to implement but my fear is
it would be only useful for advanced users and would actualy encourage to
conserve the rather broken default behavior.
Richard
_______________________________________________
mobile-firefox-dev mailing list
mobile-firefox-dev@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
