Closed Bug 888329 Opened 7 years ago Closed 6 years ago

Defect - Mouse scrollbars remain visible on the first browser we open

Categories

(Firefox for Metro Graveyard :: Browser, defect, P2)

x86_64
Windows 8.1
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Whiteboard: feature=defect c=tbd u=tbd p=1)

Attachments

(1 file, 1 obsolete file)

STR:

1) open a scrollable page
2) move the mouse to bring up mouse scrollbars
3) touch down on the page and scroll

result: both touch scroll indicator and mouse scrollbar is visible

1) open a scrollable page
2) move the mouse to bring up mouse scrollbars
3) tap the page once
4) touch down on the page and scroll

result: mouse scrollbars will hide on step #3, and will not be visible in step #4. (correct behavior)
sorry, wrong tracker.
Blocks: metrov1defect&change
No longer blocks: metrov1triage
Summary: Mouse scrollbars remain visible under certain circumstances → Defect - Mouse scrollbars remain visible under certain circumstances
Whiteboard: feature=defect c=tbd u=tbd p=0
Attached patch fix (obsolete) — Splinter Review
This does a few things - 

- adds a touchstart listener in InputSourceHelper so we transition sooner
- makes sure we fire the initial event on startup via the undefined checks on isPrecise.
- gets rid of a bunch of treatMouseAsTouch gunk we've dropped
Attachment #769429 - Flags: review?(sfoster)
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=tbd u=tbd p=1
Blocks: metrov1it10
No longer blocks: metrov1defect&change
Status: NEW → ASSIGNED
QA Contact: jbecerra
Comment on attachment 769429 [details] [diff] [review]
fix

This still isn't fixed completely even with this patch. I think there's something deeper here related to xul scrollbar visibility. The overflow css doesn't seem to work in all cases.
Attachment #769429 - Flags: review?(sfoster)
Interesting bug, for some reason the very first tab browser we create ignores our overflow css, and also ignores changes to the input broadcast property. New tabs don't have this problems. Not sure what causes this, the first tab loads early and is obscured by the start page. That might have something to do with it.
Summary: Defect - Mouse scrollbars remain visible under certain circumstances → Defect - Mouse scrollbars remain visible on the first browser we open
No longer depends on: 879565
Attached patch fix v.2Splinter Review
The trick here seems to be init normally with scrollbars, and fire off the imprecise type once the browser loads. It's an odd fix but works.
Attachment #769429 - Attachment is obsolete: true
Attachment #769917 - Flags: review?(sfoster)
Comment on attachment 769917 [details] [diff] [review]
fix v.2

Review of attachment 769917 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, works for me.
Attachment #769917 - Flags: review?(sfoster) → review+
(In reply to Wes Kocher (:KWierso) from comment #8)
> Backed out for causing the failures in bug 889694:
> http://hg.mozilla.org/integration/mozilla-inbound/rev/2dbcdd077b2c

Pushed a fix to try. The selection tests assumed imprecise on startup, I've added some code to their startup functions that sets imprecise on the input helper and fires an update. Fixed this issue locally for me.
https://hg.mozilla.org/mozilla-central/rev/382cfd96a8a8
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Tested on 2013-07-17 using latest nightly built from http://hg.mozilla.org/mozilla-central/rev/0888e29c83a3

Tested with first and second part of steps to reproduce in comment #0. I can still see the problem described in the first part. If you load this bug in Firefox Metro and you touch down on the mousepad to display the cursor and then touch and scroll you will see both the touch scroll indicator and mouse scrollbar. I tried this on a laptop and a tablet.

The second part I can no longer reproduce.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: metrov1it11
No longer blocks: metrov1it10
Confirming this is still happening, although it's caused by a different problem. Something is sending the front end a delayed mousemove after touchstart which flips us back to precise mode. I can one-off this by flipping back on touchmoves, but first I'd like to find out where that late mousemove event is coming from. That seems like it might be a bug somewhere in our front end, widget, or event state.
Blocks: 896017
Since this is a new bug, I've filed 896017. Closing as the original problem with the first tab is in fact fixed.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130806104538
Built from http://hg.mozilla.org/mozilla-central/rev/1e381c91885d

WFM
Tested on windows 8 using latest nightly. 
STR
1) open a scrollable page
2) move the mouse to bring up mouse scrollbars
3) tap the page once
4) touch down on the page and scroll

result: mouse scrollbars were hidden on step #3, and step #4.
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130815030203
Built from http://hg.mozilla.org/mozilla-central/rev/a8daa428ccbc

WFM
Tested on windows 8 using latest nightly for iteration-12. 

STR
1) open a scrollable page
2) move the mouse to bring up mouse scrollbars
3) tap the page once
4) touch down on the page and scroll

result: mouse scrollbars were hidden on step #3, and step #4.
Status: RESOLVED → VERIFIED
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.