Closed Bug 563548 Opened 14 years ago Closed 12 years ago

You can still scroll the page when overflow:hidden is on the viewport

Categories

(Firefox for Android Graveyard :: Toolbar, defect)

defect
Not set
normal

Tracking

(fennec+)

RESOLVED WONTFIX
Tracking Status
fennec + ---

People

(Reporter: martijn.martijn, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

Attached file testcase (deleted) —
See testcase, it is possible to scroll the page while panning. Since that is an overflow:hidden iframe, that should not be possible, officially. (but in Firefox, you can still use autoscroll to scroll the page, although that is considered a bug).
Using the arrow keys in Firefox works too.
Yes, that's bug 295020.
Attached file simple test case (deleted) —
Here, the red div should not be visible. On Firefox Desktop: not visible (but can be reached with the keyboard) On Firefox Mobile: the red square is fully visible On Android browser: the red square is not initially visible, but can be reached if panning
(In reply to comment #3) > On Firefox Mobile: the red square is fully visible > On Android browser: the red square is not initially visible, but can be reached > if panning The Android 2.2 browser almost gets this right. At the initial zoom level, the red square is not visible and panning is disabled. But if you zoom in, then you can pan to see the red square. One difference between Fennec and Android WebKit which we might want to fix: When the page does not specify an initial-zoom level, Android WebKit zooms to fit the viewport width, while Fennec zooms to fit the document width.
What is the status of this fix? Paul's FF4 demos depend on this. Thanks!
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0-
this may be fixed by the patch on bug 642205, can you re-test when that lands and report back here?
Depends on: 642205
tracking-fennec: 2.0- → 2.0next+
Whiteboard: resolveme 2011-03-28
These test cases are not fixed by bug 642205.
Whiteboard: resolveme 2011-03-28
OS: Windows 7 → All
Hardware: x86 → All
Version: 1.9.2 Branch → Trunk
Ben can you take a look at this?
Assignee: nobody → ben
tracking-fennec: 2.0next+ → 6+
tracking-fennec: 6+ → 7+
Ben, ping?
tracking-fennec: 7+ → +
Test case 1 does not scroll in my build. Test case 2 is something completely different, but looks a valid bug to me.
Assignee: ben → doug.turner
Assignee: doug.turner → nobody
qawanted to retest
Keywords: qawanted
Component: Panning/Zooming → General
Product: Fennec → Fennec Native
QA Contact: pan-zoom → general
For testcase 1 the iframe with text is scrollable but the page is not. For testcase 2 the page is scrollable both to the left to display the red rectangle which starts hidden and up and down. Tested only with drag scroll as I do not have access to devices with arrow keys keyboard. Tested on: Nightly 16.0a1 2012-06-17 / Aurora 15.0a2 2012-06-17 HTC Desire Android 2.2
Keywords: qawanted
Component: General → Graphics, Panning and Zooming
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #0) > See testcase, it is possible to scroll the page while panning. Since that is > an overflow:hidden iframe, that should not be possible, officially. > (but in Firefox, you can still use autoscroll to scroll the page, although > that is considered a bug). This testcase is scrollable in Chrome/Safari. The reason it is scrollable in FF on android is that the body element inside the iframe has its scrollHeight bigger than its clientHeight, and this seems reasonable to me. I guess it's a little counter-intuitive but AIUI the CSS box model indicates that this should still be scrollable, because the box for the iframe is separate from the box for the iframe's body, and setting overflow:hidden on the former should not affect the latter. I'm not sure why it is not scrollable in FF desktop, but I assume special handling was put in for this case.
(In reply to Kartikaya Gupta (:kats) from comment #13) > the former should not affect the latter. I'm not sure why it is not > scrollable in FF desktop, but I assume special handling was put in for this > case. See bug 259615.
As far as I can tell that bug doesn't cover the distinction between overflow properties on an iframe affecting the iframe's box versus the iframe's body's box.
Fine by me if you want to wontfix this bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: