Closed Bug 865513 Opened 11 years ago Closed 11 years ago

[Browser] keyboard do not display when open web sites focused on keyword edit

Categories

(Core :: DOM: Events, defect, P2)

Product:
Core
Component:
DOM: Events
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
1.1 QE3 (26jun)
Project Flags:
blocking-b2g leo+

People

(Reporter: leo.bugzilla.gaia, Unassigned)

References

Details

(Whiteboard: TaipeiWW, NeedsReview)

Attachments

(2 files)

Simple HTML to reproduce this issue
251 bytes, text/plain
Details
Patch to send focus to the contents whenever a URL is loaded
1005 bytes, patch
benfrancis
: review-
Details | Diff | Splinter Review 
* Test web site
- The other web sites are redirected to mobile page. But the below web sites are opened by PC mode
- www.daum.net
- www.naver.com

* Test Case
1. Launch Browser
2. Open www.daum.net or www.naver.com
3. Do not display keyboard although keyboard edit has focus.
4. pinch zoom in/out then keyboard will be displayed.
   or if you click keyboard edit again, you can see keyboard.

It seems that keyboard will be displayed when refresh after loading page.
It seems that we are getting "focus" event on the input field.
But just after that we are getting a "pagehide" event.
Thats causing the keyboard to be hidden.

Why gecko sends "pagehide" event during page loading? is it expected?
It seems that we are getting "focus" event on the input field.
But just after that we are getting a "pagehide" event.
Thats causing the keyboard to be hidden.

Why gecko sends "pagehide" event during page loading? is it expected?
Flags: needinfo?(bfrancis)
blocking-b2g: --- → leo?
Is this a website issue and expected? Or a problem on our end?
Starting as leo+ assuming this is a problem on our side, please renominate if this isn't the case.
blocking-b2g: leo? → leo+
I can see this issue with www.naver.com . 
Steps: 1) open www.naver.com 2) ZoomIN/ZoomOut shows keyboard.

But I don't see this issue with www.google.com .
Assignee: nobody → tkundu
Status: NEW → ASSIGNED
If I visit google.com then browser app automatically gets focus events . But if I visit www.naver.com then browser app doesn't get any focus event.

Needs to investigate how focus event is generated during loading of website.
(In reply to Leo from comment #2)
> It seems that we are getting "focus" event on the input field.
> But just after that we are getting a "pagehide" event.
> Thats causing the keyboard to be hidden.
> 
> Why gecko sends "pagehide" event during page loading? is it expected?

I tried same websites ( both www.daum.net and www.naver.com) on android also. I found that Android also doesn't show keyboard automatically . 

It seems to me expected behavior in this case should be :

1) Browser should not display keyboard app automatically after loading ( www.daum.net or www.naver.com or www.google.com ) . This is observed on Android. FFOS also does same. 

2) Browser should not try to display keyboard while getting zoomin/zoomout event . 

In Android, the default behavior for pinching zoomin/zoomout is to hide keyboard when zoomin/zoomout event comes. FFOS does not do anything when it gets zoomin/zoomout i.e. opened keyboard will remain as opened during zoomin/zoomout.  Both FFOS and Android follows this for www.google.com. But in case of www.naver.com , FFOS opens keyboard during pinching zoomin/zoomout. This needs to be investigated further and fixed .

3) Browser should display keyboard when user touch input field. Both FFOS and Android do this.
I wonder if something is causing the focus event to get stuck, the zooming somehow causes it to fire. If you just tap on a blank area of the screen it will also cause the focus event to fire, then the blur event to fire immediately afterwards.

I can no longer reproduce this on daum.net by the way, because they've started sending a mobile version of the site which doesn't have the issue.
Component: Gaia::Browser → DOM: Events
Flags: needinfo?(bfrancis)
Product: Boot2Gecko → Core
Does this repro with other major sites?
Keywords: qawanted
QA Contact: nkot
Tested Facebook, Google, Youtube, Baidu, Wikipedia, qq.com, taobao, twitter, yahoo.co.jp, bing.

Blogspot shows javascript issue.  kbrosnan states that we have issues with blogspot on ffx on android as well.


I think it would be more worthwhile to deconstruct the web pages into a minimum test case rather than testing out various pages.
bug 862700 is probably related.

Actually, I think this might be a gecko bug?  Bug 871883 which is fixed in MC.
tested it also, my results: 
ask.com, aol.com, naver.com - all these will display keyboard while getting zoomin/zoomout

google.com, yahoo.com - display keyboard only in case when tapping input fields
QA Contact: nkot
never mind about Bug 871883 this still happens in MC.
Don't have enough bandwidth to work on it right now. I may try to work on it after 3-4 days.
Assignee: tkundu → nobody
Priority: -- → P2
Target Milestone: --- → 1.1 QE3 (24jun)
Hi, this is Andre from Leo.

As suggested above, based on naver.com, I got a minimal test page where the issue is reproducible.

In the case attached, a javascript sets the focus on the text box during the onload event:

<body>
<form><input id="query" type="text"></form>

<script type="text/javascript">
window.onload = function() {
	document.getElementById('query').focus();
}
</script>
</body>

Any suggestion is welcomed.
Hi Ben, could you check if this patch makes sense?

When a URL is loaded, the focus is not on the contents (might be on the "->" button or somewhere else).

If the page loaded uses autofocus in a text input field or sets the focus at onload, the keyboard is not displayed, because the contents does not hold the focus.

As result, the keyboard is displayed when the user interacts with the contents (zoom, scroll or just touch).

The patch fix it by sending the focus to the contents always a page is loaded.

But this unveils an undesired behavior: show the keyboard at loding when the page has the autofocus. But, IMO, this is the a problem with the content or a new bug.
Attachment #764516 - Flags: review?(bfrancis)
Whiteboard: TaipeiWW, NeedsReview
Comment on attachment 764516 [details] [diff] [review]
Patch to send focus to the contents whenever a URL is loaded

Thank you for the patch, but I don't think we want this behaviour.

I discussed this with Vivien and he explained why the current behaviour is intentional. I also tested on Firefox for Android and Chrome for Android and they behave consistently.

In order to trigger the keyboard both the window and element must have focus. When web pages are calling focus on page load, the text field does get element focus (you may sometimes see the cursor flashing), but the keyboard is not triggered because the content's *window* doesn't get focus until the user touches it. This is to prevent a web page from stealing focus from the browser.

Imagine for example that you are trying to type a URL in the address bar but a web page is aggressively trying to steal focus from the browser app, it could render the browser unusable.
Attachment #764516 - Flags: review?(bfrancis) → review-
As this behaviour is intentional I am marking this as WONTFIX. If you find any instances where web content *is* able to steal focus from the browser app, please file a bug for that.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Hi Ben, thanks for the review.

But there are a few points I disagree, and I will just write down here to keep registered in case we return to this subject later.

1- Firefox browser for Android does show the keyboard when the user enters that sites (*google*, naver, aol, ask - all in PC version), without need for the user to click on the page. So the behaviour of FFOS is not consistent with the FF for Android. Chrome does as you described.

2- FFOS Browser, as is, behaves differently when the user access those sites from a link (showing the keyboard) and from inputing the URL (keyboard does not appear).

3- When the user taps in a blank area of the screen and the keyboard appears and disappears, should not be considered an intentional behaviour.
(In reply to andre.graziani from comment #20)
> 1- Firefox browser for Android does show the keyboard when the user enters
> that sites (*google*, naver, aol, ask - all in PC version), without need for
> the user to click on the page.

I can't reproduce that. Which version of Firefox for Android are you using, and which exact URLs are you visiting.

> 2- FFOS Browser, as is, behaves differently when the user access those sites
> from a link (showing the keyboard) and from inputing the URL (keyboard does
> not appear).

I can't reproduce that either. Can you provide your gecko/gaia versions and some precise steps to reproduce?

> 3- When the user taps in a blank area of the screen and the keyboard appears
> and disappears, should not be considered an intentional behaviour.

I understand this may look odd from the user's point of view. From a technical point of view, this is expected behaviour. The element focus event is not allowed to fire until the window has focus. By tapping a blank part of the web page you set the window focus, allowing the element focus to take place, but then the fact you touched the page triggers a blur on the text field, thereby hiding the keyboard.

Other than adding a workaround for this in Gecko I think the long term answer may be a more powerful keyboard API which goes beyond just showing & hiding the keyboard based on focus/blur events and can account better for these edge cases.
This issue reproduced at AU131(Mozilla build ID: 20130616070209)
Did you not reproduce this issue?

In Comment 13, this issue reproduced several pages.
It is unconvinience to user.
Flags: needinfo?(bfrancis)
(In reply to Ben Francis [:benfrancis] from comment #21)
> > 1- Firefox browser for Android does show the keyboard when the user enters
> > that sites (*google*, naver, aol, ask - all in PC version), without need for
> > the user to click on the page.

I thought you also saw that, as you commented in bug 862460, comment 1
I am using Firefox for Android 21.0 and Android Beta 22.0
To reproduce, I just typed the url of the sites above, and make sure they are in PC version. (ex. ask.com)

> > 2- FFOS Browser, as is, behaves differently when the user access those sites
> > from a link (showing the keyboard) and from inputing the URL (keyboard does
> > not appear).

As jongsoo.oh said, AU131:
gaia: f2d6ed54a236e6e3b94f0abad9f0dacb8a1cc7b3
gecko: be276cf55ce160bca09f36d9ca679a2ae20ea7cc
To reproduce, you go to google.com, it will open the mobile version. Click the "Classic" link to open PC version. The keyboard will appear when the page is loaded. But if you refresh this page (or enter the url for the pc version), the keyboard will not appear until user tap the content.

> > 3- When the user taps in a blank area of the screen and the keyboard appears
> > and disappears, should not be considered an intentional behaviour.

This one we agree it is odd for the user, as stated by jongsoo.oh as well
 
> Other than adding a workaround for this in Gecko I think the long term
> answer may be a more powerful keyboard API which goes beyond just showing &
> hiding the keyboard based on focus/blur events and can account better for
> these edge cases.

Agreed. But the patch proposed is in Gaia.
(In reply to andre.graziani from comment #24)
> I thought you also saw that, as you commented in bug 862460, comment 1

That's just what I was told, I hadn't been able to reproduce myself since.

> I am using Firefox for Android 21.0 and Android Beta 22.0
> To reproduce, I just typed the url of the sites above, and make sure they
> are in PC version. (ex. ask.com)

> To reproduce, you go to google.com, it will open the mobile version. Click
> the "Classic" link to open PC version. The keyboard will appear when the
> page is loaded. But if you refresh this page (or enter the url for the pc
> version), the keyboard will not appear until user tap the content.
> 
> > > 3- When the user taps in a blank area of the screen and the keyboard appears

I'm not able to reproduce with mobile versions of ask.com and google.com on Firefox for Android 21.0 (stable) or 23.0a1 (Nightly). However, explicity requesting the "full" or "classic" versions as you describe does cause the keyboard to appear. That does seem to indicate that the web site owners think the desirable behaviour on mobile is not to show the software keyboard, but I admit it appears to be inconsistent behaviour.

Vivien, would we consider that a bug in Firefox for Android?

> > Other than adding a workaround for this in Gecko I think the long term
> > answer may be a more powerful keyboard API which goes beyond just showing &
> > hiding the keyboard based on focus/blur events and can account better for
> > these edge cases.
> 
> Agreed. But the patch proposed is in Gaia.

As explained in comment 18, the proposed patch would break intended functionality which prevents web content rendering the browser app unusable.
Flags: needinfo?(bfrancis) → needinfo?(21)
User should otp-in for the keyboard. Otherwise the page can just call .focus/.blur in a loop and ceate an awful usability issue.
Flags: needinfo?(21)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: