Harvey Reporter
	Description • 11 years ago

Description:
Wikipedia scroll bar becomes out of place when the user presses the icon that goes to the browser.

Repro Steps:
1) Updated Buri 1.3 to Build ID: 20140127004002
2) Launch the Wikipedia app.
3) Quickly scroll down the page and press the browser button next to the settings button.
4) Observe the scroll bar.

Actual:
The Scroll bar continues to the next screen where it is out of place.

Expected:
There is not an out of place scroll bar.

Environmental Variables
Device: Buri 1.3 Mozilla
Build ID: 20140127004002
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/c40099a42c1f
Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a
Platform Version: 28.0a2 
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 100%
See video: http://www.youtube.com/watch?v=fjwvLeApEYs

	Harvey Reporter
	Comment 1 • 11 years ago

This issue does not reproduce on Buri 1.2

Environmental Variables
Device: Buri 1.2 Mozilla
Build ID: 20140128004004
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/d10e1f965d0c
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Platform Version: 26.0
Firmware Version: v1.2-device.cfg

	Jason Smith [:jsmith]
	Comment 2 • 11 years ago

Very minor bug.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 3 • 11 years ago

Do we have access to the source for this app? I suspect this behaviour might be intentional, if that dialog at the bottom is fixed-position content.

	Jason Smith [:jsmith]
	Comment 4 • 11 years ago

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> Do we have access to the source for this app? I suspect this behaviour might
> be intentional, if that dialog at the bottom is fixed-position content.

Yup. Here's the site the app launches to - http://bits.wikimedia.org/WikipediaMobileFirefoxOS/.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 5 • 11 years ago

Yeah so in this case I think this is expected behaviour. We show scrollbars over top of position:absolute content, which is what this is. Note that the content is also still scrollable while the "open in browser" and "cancel" buttons are shown - this is probably also undesirable. They should be setting overflow:hidden on the content area when those buttons are visible to fix both of these problems.

We can move this to Tech Evang, or close it as INVALID. Not sure which is more appropriate. I'm not sure why the behaviour was different in 1.2 but I'm pretty sure the behaviour as it is now is correct.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 6 • 11 years ago

That being said, the change :tn is proposing in bug 965593 might affect this. Probably worth waiting to see what happens there.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 7 • 11 years ago

So yeah, bug 965593 fixes this issue and puts the scrollbars behind the buttons.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 8 • 11 years ago

With the backout of bug 965593 this bug is likely present again.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 9 • 11 years ago

qawanted to retest now that bug 965593 has re-landed, and this bug is likely gone again. What a merry-go-round!

	Kartikaya Gupta (email:kats@mozilla.staktrace.com)
	Comment 10 • 11 years ago

(Note: retesting wanted on 1.4 for now, since bug 965593 hasn't been uplifted to 1.3 yet)

	Jason Smith [:jsmith]
	Comment 11 • 11 years ago

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9)
> qawanted to retest now that bug 965593 has re-landed, and this bug is likely
> gone again. What a merry-go-round!

jharvey - can you retest on trunk?

	Harvey Reporter
	Comment 12 • 11 years ago

This issue does not reproduce on Buri 1.4

Environmental Variables:
Device: Buri v1.4
BuildID: 20140226040201
Gaia: 80d6405725788327102cab36e8d8c017cf25fb23
Gecko: 626d99c084cb
Version: 30.0a1
Firmware Version: v1.2-device.cfg