Closed Bug 1046017 (offset-tap) Opened 9 years ago Closed 9 years ago

Taps are offset on some devices

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Version:
32 Branch
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(firefox31 unaffected, firefox32+ verified, firefox33+ fixed, firefox34+ fixed, firefox35 verified, firefox-esr31 unaffected, fennec32+)

Status:
VERIFIED FIXED
Milestone:
Firefox 35
Tracking Flags:
Tracking Status
firefox31 --- unaffected
firefox32 + verified
firefox33 + fixed
firefox34 + fixed
firefox35 --- verified
firefox-esr31 --- unaffected
fennec 32+ ---

People

(Reporter: maxbritov, Assigned: mcomella)

References

Details

(Keywords: regression)

Attachments

(1 file)

Backed out changesets 1c213218173f & 8588817f7f86 (bugs 1017427 & 1006797)
3.97 KB, patch
kats
: review+
lmandel
: approval-mozilla-aurora+
lmandel
: approval-mozilla-beta+
lmandel
: approval-mozilla-release+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release)
Build ID: 20140729130837

Steps to reproduce:

I tap on URL, but focus on URL above in ~1cm on screen.
For example on Menu - Help page I tap on one button, but selected previous button.
Same for URLs on all sites.

I have Firefox 31 and Firefox 32b2 (updated from b1 today).
Firefox 31 works fine and I have to use it now instead on 32.
Firefox 32beta have this issue and I have to search right place on screen where I can open needed URL on page :)

My device is Samsung GT-I8160 with Android 4.1.2
OS: Linux → Android
Hardware: x86_64 → ARM
tracking-fennec: --- → ?
Keywords: qawanted
Maybe related to some of the recent changes in toolbar?
Assignee: nobody → michael.l.comella
tracking-fennec: ? → 32+
As per the duplicate report this seems to affect other devices too such the Galaxy Tab.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Tap focus on URLs in Firefox 32 beta above the physical tap on my Samsung I8160 → Tap focus on URLs in Firefox 32 beta above the physical tap
I cannot reproduce this on my Samsung GT-P7510 (Galaxy Tab 10.1) using a local build (34) and 32b4, or  my Samsung GT-P5210 (Galaxy Tab 3 10.1) using 32b2 and 32b4.

However, I'm not sure I fully understand the issue and how to reproduce it.

Aaron, can you reproduce this? Is it just that clicking into web content will cause a click to occur about ~1cm (30px?) above where you tapped?
Flags: needinfo?(aaron.train)
Here's the description from the bug I opened which was duped to this one:

I have this weird problem with Firefox Beta 32.0 on my phone, but not on my tablet. The gist of it is that when the addressbar is showing, when I touch a link, the browser acts as if I pressed like 30 pixels upwards from where I pressed.

STR:

1. Go to a web page that has lines of links like Hacker News or about:
2. Press on a link in the middle of the page

Expected: Goes to that link
Actual: Goes to the link 30 pixels or so up

If I scroll down the page so the address bar disappears, then pressing the link will go to that link just fine.

I checked and "Scroll title bar" is enabled in Firefox on both my phone and tablet.

I think this started happening about a week or two ago, but I don't use the browser on my phone regularly, so it's possible it's been happening longer.

The phone is a Samsung Galaxy something-or-other (SGH-T599) running Android 4.1.2.

My tablet is a Samsung Galaxy Tab 10.1 (GT-P7510) running Android 4.0.4.
(In reply to Michael Comella (:mcomella) from comment #4)
> I cannot reproduce this on my Samsung GT-P7510 (Galaxy Tab 10.1) using a
> local build (34) and 32b4, or  my Samsung GT-P5210 (Galaxy Tab 3 10.1) using
> 32b2 and 32b4.
> 
> However, I'm not sure I fully understand the issue and how to reproduce it.
> 
> Aaron, can you reproduce this? Is it just that clicking into web content
> will cause a click to occur about ~1cm (30px?) above where you tapped?

Whoops, missed this NA. Unfortunately, I cant. I don't have the device reported against. I tried a Note/SII of somewhat similar equivalence with and couldn't reproduce.
Flags: needinfo?(aaron.train)
Here's data sheets for the two devices reported as having issues:

* http://www.gsmarena.com/samsung_galaxy_ace_2_i8160-4559.php
* http://www.samsung.com/us/mobile/cell-phones/SGH-T599DAATMB-specs

Both are running Android 4.1.2. Both have 800x480 screens. I didn't notice other similarities.

I double-checked everything on my phone:

1. verified the problem still exists with Firefox Beta (32.0) using the STR in comment #5
2. uninstalled Firefox Beta
3. installed Firefox -- problem does not exist with Firefox (31.0)
4. uninstalled Firefox
5. installed Firefox Beta (32.0) again
6. verified the problem still exists with Firefox Beta (32.0)

Also, one thing I noticed with Firefox Beta that doesn't happen with Firefox is that with Firefox, when you go to a web page, you see the entire page--the nav bar doesn't cover the top part of the page. With Firefox Beta, when you go to a web page, the nav bar does cover the top part of the page. In order to see the top part, you have to scroll up just enough to make the nav bar disappear, but not so much that the page starts scrolling up.

Further, if the page isn't long enough to scroll, then you can't make the nav bar go away and you can't see the top part of the page at all.
Aaron, do you have any devices running 4.1.2 to test on?
Flags: needinfo?(aaron.train)
(In reply to Will Kahn-Greene [:willkg] from comment #7)
> Also, one thing I noticed with Firefox Beta that doesn't happen with Firefox
> is that with Firefox, when you go to a web page, you see the entire
> page--the nav bar doesn't cover the top part of the page. With Firefox Beta,
> when you go to a web page, the nav bar does cover the top part of the page.
> In order to see the top part, you have to scroll up just enough to make the
> nav bar disappear, but not so much that the page starts scrolling up.
> 
> Further, if the page isn't long enough to scroll, then you can't make the
> nav bar go away and you can't see the top part of the page at all.

This sounds like undesireable behavior; I can't reproduce it on my Nexus 4.

Will, do you only see this on your 4.1.2 devices?

Aaron, do you see this at all?
Flags: needinfo?(willkg)
Switched from 4.1.2 to CM 11 (4.4.4 by TeamCanjica) yesterday.
Issue still with me :(
I8160

ps. Hm... I will try find another phones with 800x480
(In reply to Michael Comella (:mcomella) from comment #9)
> (In reply to Will Kahn-Greene [:willkg] from comment #7)
> > Also, one thing I noticed with Firefox Beta that doesn't happen with Firefox
> > is that with Firefox, when you go to a web page, you see the entire
> > page--the nav bar doesn't cover the top part of the page. With Firefox Beta,
> > when you go to a web page, the nav bar does cover the top part of the page.
> > In order to see the top part, you have to scroll up just enough to make the
> > nav bar disappear, but not so much that the page starts scrolling up.
> > 
> > Further, if the page isn't long enough to scroll, then you can't make the
> > nav bar go away and you can't see the top part of the page at all.
> 
> This sounds like undesireable behavior; I can't reproduce it on my Nexus 4.
> 
> Will, do you only see this on your 4.1.2 devices?

I only have two devices with Android on them. One is my phone which is running Android 4.1.2 and is exhibiting the problems I specified with Firefox Beta. The other is my Samsung Galaxy Tab 10.0 with Android 4.0.something and it works just fine and isn't exhibiting any of the problems I mentioned.
Flags: needinfo?(willkg)
Not on me today, maybe SoftVision has
Flags: needinfo?(aaron.train) → needinfo?(fennec)
Both on NovaThor: http://www.gsmarena.com/results.php3?sFreeText=novathor

T599 vs I8160:
NovaThor 8420 vs 8500
Mali-400 vs Mali-400MP4
Ram 1GB vs 768MB
2013 vs 2012 :)

I check Sony ST21i (320x480 180 ppi) and Samsung S7562 Galaxy S Duos (800x600 233ppi)
Both fine with 32beta.
Tried to reproduce the issue using the following devices:
1. Samsung Galaxy Ace S5830 (Android 2.3);
2. Samsung Galaxy S2 (Android 4.1.2);
3. LG Optimus 4X (Android 4.1.2).

Try to activate "Show touches" option in Android developer options in order to check if it's not a touchscreen issue.
Flags: needinfo?(fennec)
I enabled "show touches" on my phone (SGH-T599, Android 4.1.2) and it's showing the touch event where I touch, but the link the browser goes to is well above where I touched.
Renoming because I'm not sure what I can do if we can't repro in house - maybe someone else has some ideas?
Assignee: michael.l.comella → nobody
Status: ASSIGNED → NEW
tracking-fennec: 32+ → ?
Actually, I can do some regression hunting. Feel free to nom.
Assignee: nobody → michael.l.comella
Status: NEW → ASSIGNED
Noting for those who can reproduce, it would be helpful if you could use mozregression to help find a regression-window http://mozilla.github.io/mozregression/

E.g, `mozregression --app=fennec --bad=2014-08-20 --good=2014-xx-xx` and go from there
I downloaded the latest nightly, was able to reproduce the issue on my phone (SGH-T599, Android 4.1.2). I then went through nightly builds until I found one that worked.

The most recent nightly build that doesn't exhibit the problem for me is this one (2014-05-27):

http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2014/05/2014-05-27-03-02-02-mozilla-central-android-armv6/fennec-32.0a1.multi.android-arm-armv6.apk

Everything after that (2014-05-28+) exhibits the problems.
Most likely culprit is bug 1006797. If somebody can repro they might want to back that out and see if it fixes the problem.
I backed out bug 1006797, and bug 1017427 (kats recommended I back the latter out to backout the former cleanly), and had willkg try out my build (https://people.mozilla.org/~mcomella/apks/mcomella-1046017_01.apk) but the issue still existed.
Will did you run the app Fennec mcomella? Not the app Nightly. I agree with Kats that 1006797 looks like the bug most likely to cause this behavior. I don't see anything in the regression range that comes before that bug that seems likely.
Flags: needinfo?(willkg)
I don't have enough space on my phone for multiple installs of Firefox, so I had to remove the existing installs to install the build Michael did.

So I'm absolutely positive I installed and ran that build.
Flags: needinfo?(willkg)
Confirm: cbe4f69c2e9c - fine, e017c15325ae - not.
Build from comment #22 - not.
I've tested on Alcatel OT-990(armv6) (Android 4.0.4 - CyanogenMod 9) with low res 320 x 480 pixels.
Still not able to reproduce the issue.
Neither here with my SII (4.1.2) across all channels.

Must be something else in that window.
Keywords: qawanted
Summary: Tap focus on URLs in Firefox 32 beta above the physical tap → Tap focuses on URLs in Firefox 32 beta above the physical tap
Mike - Are you continuing to investigate this with Will?
tracking-fennec: ? → +
Flags: needinfo?(michael.l.comella)
(In reply to Mark Finkle (:mfinkle) from comment #28)
> Mike - Are you continuing to investigate this with Will?

Yes.

I've been passing builds to willkg where I checked out revisions instead of backing out - both the first build with (https://hg.mozilla.org/mozilla-central/rev/8588817f7f86) and without bug 1006797 (https://hg.mozilla.org/mozilla-central/rev/9fa72130d50b) do not exhibit the issues in this bug - I'll do some more regression testing.
Flags: needinfo?(michael.l.comella)
It would be good to know if the issue is still problematic or not if you head into settings and make sure that the title-bar (dynamic toolbar) is always visible (under display settings).

If not an issue then, it would be a good workaround to document this at time of release.
If I disable Settings -> Display -> Scroll title bar, then the problems go away and things work fine.
Oops! I used the wrong build command - turns out the backout of bug 1006797 and bug 1017427 fixed the issue. Sorry for the confusion!

kats, do you know what we might be able to do to fix the issue, and should we back it out?
I don't think we should back it out; I'd rather try to fix it in-place. However I don't understand why this only reproduces for some people. Do we have STR that work consistently? Factors that might affect this are screen size, the specific URL being used, and the option mentioned in comment 31.
Blocks: 1006797
status-firefox31: --- → unaffected
status-firefox32: --- → affected
Flags: needinfo?(bugmail.mozilla)
I can reproduce it trivially and consistently using the STR I listed in comment #5. 

It doesn't seem to be a problem with specific urls. All of the following have issues:

1. news.ycombinator.com
2. about:firefox (which makes it hard to figure out what version I'm using)
3. support.mozilla.org
4. google.com
etc.
(In reply to Will Kahn-Greene [:willkg] from comment #31)
> If I disable Settings -> Display -> Scroll title bar, then the problems go
> away and things work fine.

Same for me. Issue gone away when scroll title bar disabled.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #33)
> However I don't understand why this only reproduces for some people. Do we
> have STR that work consistently?

The STR seems to be simple enough that this issue is likely device-specific though we don't have multiple versions of the problem devices to identify that this definitely is the case. Affected devices are:
  * Samsung GT-I8160
  * Samsung SGH-T599

> Factors that might affect this are screen
> size, the specific URL being used, and the option mentioned in comment 31.

We haven't found any consistent device specifications (outside of specific models) that reproduce the issue.

Kats, I'm unfamiliar with the affected code - who would be appropriate to assign this bug to? Should I give it back to Chris Lord?
Flags: needinfo?(bugmail.mozilla)
Chris, thoughts? If i could repro this i would be able to take it but since i can't your guesses are probably more useful than mine.
Flags: needinfo?(bugmail.mozilla) → needinfo?(chrislord.net)
Successfully reproduced the bug in HTC Desire 700 dual SIM android 4.1.

Unable to reproduce the bug in Samsung Galaxy Grand 2 SMG7102 android 4.4.
2xMali-400 and 1xMali-400MP4 phones
Re'nomming to see if anyone else can take a look at this because I think it's out of my area of expertise. Via IRC, kats said he didn't have enough cycles and recommended snorp.

See comment 32 for the regressing bug info.
tracking-fennec: + → ?
Flags: needinfo?(snorp)
Assignee: michael.l.comella → nobody
Status: ASSIGNED → NEW
Alias: offset-tap
Severity: normal → major
Keywords: regression
Summary: Tap focuses on URLs in Firefox 32 beta above the physical tap → Tap focuses on URLs in above the physical tap
Summary: Tap focuses on URLs in above the physical tap → Taps are offset on some devices
Release Note Request (optional, but appreciated)
[Why is this notable]: Taps are offset on some devices
[Suggested wording]: On some Android devices, taps to links are offset
[Links (documentation, blog post, etc)]: Workaround: Settings -> Display -> Uncheck scroll title bar
relnote-firefox: --- → ?
This is also affecting text selection - once the address bar or the text selection action bar are visible, there is a clear gap between the text selection handles and the selected text - see my duplicated bug 1062234.
I'm using a Galaxy S3 Mini (GT-I8190), and I've come across a report on Mozilla Input from somebody else using the same device: https://input.mozilla.org/en-GB/dashboard/response/4584084
Assignee: nobody → botond
tracking-fennec: ? → 32+
Seeing as people aren't responding to their needinfos I'm ok with backing out the offending patch and restoring the original bug which seems less severe. I don't think anybody has cycles to look into this at the moment.
Assignee: botond → nobody
:mcomella, since you already put together a backout patch, mind landing it? rs=me
Yes so far most of the bugs and support issues we have seen are Samsung phones running early JellyBean devices. Android 4.1
It would be nice if the workaround was posted on Google Play where people would read it.
I had deleted the previous backout patches and had to reconstruct this so hopefully it all worked correctly.
Attachment #8484565 - Flags: review?(bugmail.mozilla)
Assignee: nobody → michael.l.comella
Status: NEW → ASSIGNED
Attachment #8484565 - Flags: review?(bugmail.mozilla) → review+
Note to self: Verify backout with Will, then backout of 33 and 34.
Flags: needinfo?(michael.l.comella)
https://hg.mozilla.org/mozilla-central/rev/c5e86d734d2e
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox32: affected → wontfix
status-firefox35: affected → fixed
status-firefox-esr31: --- → unaffected
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Lawrence - the UA team would appreciate if this were added to your chemspill release.  This is because:
1) This issue will likely be underreported due to it's disruptive nature
2) ~1% of our 32 Android feedback is mentioning this issue
3) In SUMO we have 1 report + 7 votes on android (avg ~10 Android questions/day and ~40 Android votes/day for reference)

Thanks
Clearing the stale needinfo requests. Adding one for comment 54.
Flags: needinfo?(snorp)
Flags: needinfo?(lmandel)
Flags: needinfo?(chrislord.net)
Do we know how widespread the problem was that we originally patched in bug 1006797 as it seems like that affected more devices. I'm more concerned that we would be reintroducing a worse experience for all devices.
I find the graphic glitch unpolished but bearable. Where as having the main way to interact with the browser horribly inconsistent on Samsung Android 4.1 devices is unbearable.
@AaronMT - I agree with Kevin.  For the record, I've seen some vague graphics feedback that could be attributable to bug 1006797, but I have a lot better evidence of this bug being an issue users care about.  My SUMO a didn't immediately know of any threads regarding the graphics issue either.

Thanks
Could those affected who commented in this bug try out Nightly (09/06) and confirm wether this is fixed for you? Please comment back here.
34 nightly not fixed. 35 nightly fixed.
Yes, fixed in the current nightly.
I think android 4.1 would most specific than samsung devices. This is because the issue has been noticed in HTC Desire 700.

Another point which I would like to bring to notice is that the title bar of aurora or firefox beta (in the affected devices) appears over the webpages instead of dragging it down. This is how google appears with the title bar open:
https://www.dropbox.com/s/8kjv62mec0bpa74/Screenshot_2014-09-07-19-41-13_1.jpg?dl=0

Notice that the 'image' option is hidden behind the title bar, unlike Firefox stable:
https://www.dropbox.com/s/en718xxx6ne1aju/Screenshot_2014-09-07-19-43-30_1.jpg?dl=0

The real issue is not with the tap but with the webpage scroll. When the title bar appears, the webpage is supposed to scroll down by the width of the title bar, which does not take place in the affected devices. But the other functionalities (like tapping) do get shifted. So, the issue can be solved by looking into the patch of auto scrolling, not tapping. The height above which a tap is being focussed is simply the width of the title bar. If the webpage would have scrolled down when the title bar appeared, the tap would focus in the right place.

Gramercy...
(In reply to Aaron Train [:aaronmt] from comment #60)
> Could those affected who commented in this bug try out Nightly (09/06) and
> confirm wether this is fixed for you? Please comment back here.

I just installed the latest nightly (2014-09-08) from nightlies.mozilla.org and the issues I describe in comment #5 and comment #7 are not present. i.e. It's fixed for me.
Thanks for checking.
status-firefox35: fixed → verified
Comment on attachment 8484565 [details] [diff] [review]
Backed out changesets 1c213218173f & 8588817f7f86 (bugs 1017427 & 1006797)

kats, can you add to the risks here?

Approval Request Comment
[Feature/regressing bug #]:
  bug 1006797 (and bug 1017427, in order to backout cleanly)

[User impact if declined]:
  Some users will have two issues:
    1) Taps on the screen will trigger about a navigation-bar-height higher than they were physically on the screen.
    2) At the top of a page, the navigation bar will cover the top of the page's content until it is scrolled away
  This affects some Samsung devices on Android 4.1. See comment 54 for some perspective on user impact.

[Describe test coverage new/current, TBPL]:
  No test coverage (as it's quite device specific)

[Risks and why]: 
  I'm unfamiliar with this code and just backed it out - I needinfo'd kats to describe the risks.

[String/UUID change made/needed]: None
Attachment #8484565 - Flags: approval-mozilla-release?
Attachment #8484565 - Flags: approval-mozilla-beta?
Attachment #8484565 - Flags: approval-mozilla-aurora?
Flags: needinfo?(michael.l.comella) → needinfo?(bugmail.mozilla)
The backout will obviously restore bug 1006797. I don't think there much additional risk though since the code has been mostly untouched since then; I don't expect other changes since then to have gotten intertwined here.
Flags: needinfo?(bugmail.mozilla)
Comment on attachment 8484565 [details] [diff] [review]
Backed out changesets 1c213218173f & 8588817f7f86 (bugs 1017427 & 1006797)

As the issue reported in bug 1006797 is preferable to the issue reported in this bug, let's take the backout on Aurora and Beta. Approved for both Aurora and Beta.
Attachment #8484565 - Flags: approval-mozilla-beta?
Attachment #8484565 - Flags: approval-mozilla-beta+
Attachment #8484565 - Flags: approval-mozilla-aurora?
Attachment #8484565 - Flags: approval-mozilla-aurora+
Comment on attachment 8484565 [details] [diff] [review]
Backed out changesets 1c213218173f & 8588817f7f86 (bugs 1017427 & 1006797)

During today's channel meeting we decided to chemspill for this bug. Approved for release.
Attachment #8484565 - Flags: approval-mozilla-release? → approval-mozilla-release+
Firefox 33 beta2 and Firefox 32.0.1RC - both fine on my phone. Thanks!

ps.And I'm not on 4.1.2, I'm on CM11 4.4.4

pps. Hm... issue coming from 1006797 which marked as fixed for FF32. Hehe, why I can see that garbage on Samsung S3 and S4 with FF 32.0
Yes unfortunately we had to trade one problem for another. I really do hope we get the traded problem fixed.
Status: RESOLVED → VERIFIED
status-firefox32: fixed → verified
This bug was relnoted in Firefox 32. The relnote flag doesn't want to let me select 32+ for some reason. Need to follow up with Bugzilla admin.
Thanks for testing all, we pushed an update to Firefox on Google Play. You should receive an update in the next few hours.
I just posted a new patch in bug 1006797 (along with a try push). Could someone that could reproduce this bug please test it to confirm that this bug doesn't occur.
(In reply to Matt Woodrow (:mattwoodrow) from comment #76)
> I just posted a new patch in bug 1006797 (along with a try push). Could
> someone that could reproduce this bug please test it to confirm that this
> bug doesn't occur.

Url to test apk?
Both issues (this one and 1006797) seems fixed on my device. Thanks.
Great, thanks for checking that.
Works fine for me, too, as far as this bug is concerned. Can't say anything about the other bug (1006797) though.
Reset the relnotes flags (cf comment #74). It was part of the release notes anyway. Just get ride of this from our radar.
relnote-firefox: ? → ---
Flags: qe-verify+
OFF

Please, people who affected this issue, could you check another issue on your phones?
Like this issue I see it on my Samsung Ace 2 (I-8160) and not on another phones.

When scrolling log page from down to up I have random think horizontal lines.
Bad quality, sorry: https://drive.google.com/file/d/0B3wtHYJkVb1eTERpUjQ1aERNdUE
On video I scroll down - everything fine, then I scroll up and you can see that lines.
Then I scroll down again and everything fine again.

It can be another exclusive on our phones. I can create new bug then.
Firefox 34 is current betas from market.
Thanks
(In reply to Maxim Britov from comment #84)
> OFF
> 
> Please, people who affected this issue, could you check another issue on
> your phones?
> Like this issue I see it on my Samsung Ace 2 (I-8160) and not on another
> phones.
> 
> When scrolling log page from down to up I have random think horizontal lines.
> Bad quality, sorry:
> https://drive.google.com/file/d/0B3wtHYJkVb1eTERpUjQ1aERNdUE
> On video I scroll down - everything fine, then I scroll up and you can see
> that lines.
> Then I scroll down again and everything fine again.
> 
> It can be another exclusive on our phones. I can create new bug then.
> Firefox 34 is current betas from market.
> Thanks

That looks like bug 1009306, which is supposed to be fixed in 34.
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #85)
> (In reply to Maxim Britov from comment #84)
> > OFF
> > 
> > Please, people who affected this issue, could you check another issue on
> > your phones?
> > Like this issue I see it on my Samsung Ace 2 (I-8160) and not on another
> > phones.
> > 
> > When scrolling log page from down to up I have random think horizontal lines.
> > Bad quality, sorry:
> > https://drive.google.com/file/d/0B3wtHYJkVb1eTERpUjQ1aERNdUE
> > On video I scroll down - everything fine, then I scroll up and you can see
> > that lines.
> > Then I scroll down again and everything fine again.
> > 
> > It can be another exclusive on our phones. I can create new bug then.
> > Firefox 34 is current betas from market.
> > Thanks
> 
> That looks like bug 1009306, which is supposed to be fixed in 34.

Or actually, bug 1014333, which was marked as a dup of 1009306
This still occurs when Full-screen browsing is enabled in Firefox Nightly (formerly Aurora) 56.0a1 (2017-07-04).Device is OnePlus 3T running OxygenOS 4.1.6 / Android 7.1.1
Please file a new bug, this one is resolved.
Using onePlus5 Firefox beta (latest). Having the same issue as I type this comment. I have to click about 1 can under a button for it to react.  Context menus like copy and paste appear directly over the editing field in some occasions too. I think it is relavent
After doing some testing I found it has to do with full screen being enabled, disabling and restarting Android browser solves this.
Flags: qe-verify+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.