937929 - Possible to open awesomescreen with awesomebar hidden

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Browser, defect)

Description

[Lucas Adamski [:ladamski]]

Attachment: STR 1

Sorry for the convoluted summary.  Basically if you scroll down far enough in the browser to hide the nav UI, then tap repeatedly at the top of the view, you occasionally end up with the bookmarks/history view popping up without the URL bar being visible.  This results in the user being somewhat stuck.  See videos for STR.

Comment 1

[Lucas Adamski [:ladamski]]

Attachment: STR 2

Comment 2

[Lucas Adamski [:ladamski]]

Ver: Peak 1.2, git 2013-11-08 13:25:01, build ID 20131108153655

Comment 3

[Preeti Raghunath(:Preeti)]

Lucas,

The rate of reproducibility seems inconsistent. Do you see different results?

Comment 4

[Ben Francis [:benfrancis]]

It looks like you managed to trigger the awesomescreen while the awesomebar was in its hidden state. The awesomescreen is triggered by a focus event on a text field which is not visible on the screen so this is somewhat surprising but I can definitely reproduce it on the current master.

It's pretty hard to trigger this and it is possible to escape the awesomescreen by selecting a bookmark or history item, but this is really not ideal!

Comment 5

[Ben Francis [:benfrancis]]

Dale, do you think this could be caused by event target fluffing? Do we "fluff" text inputs?

Comment 6

[Jason Smith [:jsmith]]

QA Wanted - Can we find out if this is a regression or not?

Comment 7

[Dale Harvey (:daleharvey)]

I dont think the fluffing code cares whether the element is displayed or not (code is http://mxr.mozilla.org/mozilla-central/source/layout/base/PositionedEventTargeting.cpp#155) that would be a bug, can fix in the browser but probably best in platform

Comment 8

[Dale Harvey (:daleharvey)]

So tested locally and display: none'd elements are ignored during fluffing, they dont get frames and so are ignored, so this is a bug inside the browser code

Comment 9

[Matthew Vaughan]

This issue does NOT reproduce for me on the 11/13/2013 1.1 build. Instead, when I tapped at the top of a web page, the only thing that would sometimes appear would be the Notification area expanding. 

Additionally, on the 11/08/13 1.2 build, I was able to reproduce this issue.

- 1.1 BUILD -
Environmental Variables:
Device: Leo v1.1 COM RIL
BuildID: 20131113041204
Gaia: cdcb99873ad8133a6500884feee5a3e0e957d302
Gecko: 3d28e6cbacce
Version: 18.0
RIL Version: 01.01.00.019.281

Comment 10

[Preeti Raghunath(:Preeti)]

Blocking since we are unable to enter the URL bar

Comment 11

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/13698

Here's a patch to make sure the awesomebar is always shown when the awesomescreen is open.

I'm a little uncomfortable about the fact that I'm not 100% sure how this is happening, but this at least this mitigates the effect to fix the blocker.

I'm not overly concerned because Botond is in the process of completely refactoring the hiding/showing address bar code, but if anyone wants to investigate this further then feel welcome. It shouldn't be possible to focus an input element which isn't on the screen! It could be something to do with the hacks we added to make integration tests pass, we added a click listener as well as the focus listener to the URL input for example, but this shouldn't be possible to trigger when the address bar is hidden either.

Comment 12

[Lucas Adamski [:ladamski]]

There may be a specific 100% STR, but for me it was inconsistent (but frequent enough to be a problem).

Comment 13

[Matthew Vaughan]

I believe I've found a regression window for this issue, but since the repro is kind of low it may not be the true window. While testing, I tapped the top of a couple web pages for roughly about 5 minutes total on each build I tested. If the issue did occur, it would only take me ~1.5 minutes, give or take about 1/2 minute, to get it to happen. I used "www.newyorker.com" and "www.buzzfeed.com" to test this.

One interesting correlation I saw between these two builds was the e.me search bar. In the 8/06 build, the search bar is simply a line with a magnify glass on the right side. In the 8/07 build, the search bar is a text box containing the words "I'm thinking of..." with a white background.

- Works -
Environmental Variables:
Device: Buri v1.2 MOZ RIL
BuildID: 20130806104538
Gaia: 42c4efb7550820b7b6d6086d419a32a9e0cad174
Gecko: 1e381c91885d
Version: 26.0a1
Firmware Version: 20131104

- Broken -
Environmental Variables:
Device: Buri v1.2 MOZ RIL
BuildID: 20130807070231
Gaia: 322389dddc458c3105978b7db6f485d8894cc487
Gecko: 1fb5d14e8348
Version: 26.0a1
Firmware Version: 20131104

Comment 14

[Jason Smith [:jsmith]]

The only commit that landed in the browser app on 8/6 was bug 796563, but that bug seems unlikely to be the cause of this regression. Could this be a gecko regression?

Comment 15

[Dale Harvey (:daleharvey)]

Comment on attachment 832171 [details] [diff] [review]
https://github.com/mozilla-b2g/gaia/pull/13698

Sorry for taking a while to review, I wanted to find the root cause, I think its possible event fluffing is causing this as the elements are only translated off screen.

However would prefer this be fixed by not triggering the awesome screen if the url bar is hidden, this still gives us the strange behaviour of switching to the awesome screen when a user is clicking on web content

Comment 16

[Dale Harvey (:daleharvey)]

and as for what is causing it, at a guess it would be improvements to the notification code in the system app, which changed the event handling behavious around the top of the screen, I would expect this bug has been around the whole time, just hidden

Comment 17

[Jason Smith [:jsmith]]

(In reply to Dale Harvey (:daleharvey) from comment #16)
> and as for what is causing it, at a guess it would be improvements to the
> notification code in the system app, which changed the event handling
> behavious around the top of the screen, I would expect this bug has been
> around the whole time, just hidden

If that's the case, then bug 900279 caused this.

bug 900279 was the Gaia landing of the Web Notifications API.

Comment 18

[Kai-Chih Hu [:khu]]

koi+ is for 1.2. We should use 1.2 target milestone rather than 1.3 target milestone.

Comment 19

[Gregor Wagner [:gwagner]]

(In reply to Kevin Hu [:khu] from comment #18)
> koi+ is for 1.2. We should use 1.2 target milestone rather than 1.3 target
> milestone.

Kevin, please stop modifying milestones for our team. They are the same date. I try to come up with some uniform tracking approach for our team and using multiple tracking milestones for a single sprint doesn't help at all.

Comment 20

[Kai-Chih Hu [:khu]]

Hi,Gregor, this is a koi+ bug. Koi+ bugs should use 1.2 target milestones, not 1.3 milestones even they are the same dates. Does it make sense for you? Or do I miss anything here? Thanks.

Comment 21

[Kai-Chih Hu [:khu]]

Hi, Gregor, or is this one planned to be landed in 1.3? In this case, my understanding is it should be marked as 1.3+, not koi+. Can you help to clarify? Thanks.

Comment 22

[Gregor Wagner [:gwagner]]

(In reply to Kevin Hu [:khu] from comment #21)
> Hi, Gregor, or is this one planned to be landed in 1.3? In this case, my
> understanding is it should be marked as 1.3+, not koi+. Can you help to
> clarify? Thanks.

I asked Preeti if RE cares about using 1.2 and 1.3 target milestones and she said RE doesn't care. Candice also said I can use 1.3 since it's the same date. So I started tracking everything with 1.3 milestones since I only care about the date. Every team is using these flags in a different way and I have never seen a mail that we are required to use those milestones in a specific way.
I have our team queries now showing 1.3 target milestones so it doesn't help if you start changing them again.

Comment 23

[Kai-Chih Hu [:khu]]

> I asked Preeti if RE cares about using 1.2 and 1.3 target milestones and she
> said RE doesn't care. Candice also said I can use 1.3 since it's the same
> date. So I started tracking everything with 1.3 milestones since I only care
> about the date. Every team is using these flags in a different way and I
> have never seen a mail that we are required to use those milestones in a
> specific way.
> I have our team queries now showing 1.3 target milestones so it doesn't help
> if you start changing them again.

Okay. Let me change it back. I just tried to fix it. If no one cares about the 1.2 target milestones, I don't understand why they were created. This bug is in your team. It's your call to determine how you're gonna manage them. I just personally, don't think it's reasonable for koi+ bugs to use 1.3 milestones, and for 1.3 bugs to use 1.2 milestones. Or, maybe we should discuss about it to have a better way to manage these target milestones v.s. versions. Thanks for your information.

Comment 24

[Gregor Wagner [:gwagner]]

(In reply to Kevin Hu [:khu] from comment #23)
> > I asked Preeti if RE cares about using 1.2 and 1.3 target milestones and she
> > said RE doesn't care. Candice also said I can use 1.3 since it's the same
> > date. So I started tracking everything with 1.3 milestones since I only care
> > about the date. Every team is using these flags in a different way and I
> > have never seen a mail that we are required to use those milestones in a
> > specific way.
> > I have our team queries now showing 1.3 target milestones so it doesn't help
> > if you start changing them again.
> 
> Okay. Let me change it back. I just tried to fix it. If no one cares about
> the 1.2 target milestones, I don't understand why they were created. This
> bug is in your team. It's your call to determine how you're gonna manage
> them. I just personally, don't think it's reasonable for koi+ bugs to use
> 1.3 milestones, and for 1.3 bugs to use 1.2 milestones. Or, maybe we should
> discuss about it to have a better way to manage these target milestones v.s.
> versions. Thanks for your information.

No worries. I was just surprised why half of the bugs disappeared from my queries last week :)
And now back to the original bug here.

Ben, Dale, any update here?

Comment 25

[Ben Francis [:benfrancis]]

Dale, do you have a proposed alternative solution?

We could try to display:none the element when the hide transition has completed, or make a change to event fluffing in Gecko?

Comment 26

[Dale Harvey (:daleharvey)]

The clean in browser solution is to not show the awesome screen when the address bar is hidden, looking at an even fluffing fix, should probably not click on offscreen targets

Comment 27

[Ben Francis [:benfrancis]]

Comment on attachment 832171 [details] [diff] [review]
https://github.com/mozilla-b2g/gaia/pull/13698

Updated patch.

I tried adding a conditional to not show awesomescreen when the address bar is hidden, but the text input still gets focused and the keyboard is displayed, even if you immediately try to blur the input or stop the event propagating.

So instead I've disabled the input element when the address bar is hidden so neither the focus or click events get fired.

A platform patch would still be preferable but this is a cleaner Gaia fix.

Comment 28

[Dale Harvey (:daleharvey)]

Comment on attachment 832171 [details] [diff] [review]
https://github.com/mozilla-b2g/gaia/pull/13698

Perfect, will file a platform bug, but this is a clean fix

https://github.com/mozilla-b2g/gaia/commit/a89d50442cbf800a26e1610d95321c48e00eb4a1

one nit, commit messages should refer to what you did, not what the bug was "Disable url bar when hidden to prevent accidental clicks" or some such

Comment 29

[Dale Harvey (:daleharvey)]

filed platform: https://bugzilla.mozilla.org/show_bug.cgi?id=941712

Comment 30

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted a89d50442cbf800a26e1610d95321c48e00eb4a1 to:
v1.2: e910c06ef751bf019c33cfc7eb5b5b6e7fa6edf7

Comment 31

[Josh Schmitt [Joshs]]

The bookmarks/history view no longer occasionally appears when tapping on the top bar in the latest Buri 1.2 and Master 1.3 builds

1.2 Environmental Variables:
Device: Buri v1.2 COM RIL
BuildID: 20131205004003
Gaia: 0659f16b9790b1cf9eba4d80743fcc774d2ffe3a
Gecko: af2c7ebb5967
Platform Version: 26.0
RIL Version: 01.02.00.019.102 
Firmware Version: V1.2_20131115

1.3 Environmental Variables:
Device: Buri v1.3 MOZ RIL
BuildID: 20131205040201
Gaia: 1dd0e5c644b4c677a4e8fa02e50d52136db489d9
Gecko: 725c36b5de1a
Version: 28.0a1
Firmware Version: V1.2_20131115