Closed Bug 868742 Opened 7 years ago Closed 7 years ago

Nested Frame can not be scrolled vertically in Mobile Firefox

Categories

(Core :: Layout, defect)

21 Branch
ARM
Android
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla24
Tracking Status
firefox21 --- wontfix
firefox22 --- fixed
firefox23 --- fixed
firefox24 --- fixed
relnote-firefox --- 22+

People

(Reporter: sfleiter, Assigned: kats)

References

(Blocks 1 open bug, )

Details

(Keywords: regression)

Attachments

(1 file)

Hi,

this bug is about a scrolling (of frames) regression from Mobile Firefox 21 onwards.

Steps:
- Install Firefox Mobile from 21 (current Beta) to 23 (current nightly)
  Tested on Samsung Galaxy Note 2 and Google Nexus 7.
- Open $URL which is in German and contains a nested frameset.
- Click "Alle Veranstaltungen" in the left navigation bar.
  The content frame should now contain the word "Veranstaltungskalender" at the very top.
- Try to scroll down that frame which will not work.

Expected:
- Should scroll as it does with desktop Firefox or mobile Chrome browser.

Bonus Step:
- Retry with Firefox Mobile 20.0.1 (current release)
- Notice that the frame scrolls as expected
Loading the page http://www2.muho-mannheim.de/ by itself in desktop FF shows that the body of the document has a clientHeight 6 pixels shorter than the scrollHeight. This results in the inability to scroll it on mobile, because we incorrectly detect the body as the scrollable element rather than the document element. Furthermore trying to actually scroll the body element by increasing its scrollTop value doesn't actually move it anywhere.

This seems like a regression in layout. It is very similar to the problem in bug 755971.
Component: General → Layout
Product: Firefox for Android → Core
Version: Trunk → 21 Branch
Also to clarify a bit, the problem can be reproduced on desktop as follows:

1) Load http://www2.muho-mannheim.de/
2) Open the developer console or firebug
3) Examine the values for "document.body.clientHeight" and "document.body.scrollHeight". Note that clientHeight < scrollHeight.
4) Try increasing the scrollTop on the body. "document.body.scrollTop += 1"
5) Check to see the new scrollTop "document.body.scrollTop"

Note that in step 5 it returns 0 even though it should be 1.
We can fix the original bug with this patch (which is more correct) which uses the new properties added back in bug 766937. I think there's still an underlying layout regression that triggered this bug but that might actually be expected behaviour. We can defer that to if/when it manifests some other way.
Assignee: nobody → bugmail.mozilla
Attachment #753812 - Flags: review?(mark.finkle)
Attachment #753812 - Flags: review?(mark.finkle) → review+
https://hg.mozilla.org/mozilla-central/rev/94aa313f23d8
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Comment on attachment 753812 [details] [diff] [review]
Use scroll(Left|Top)Max in fennec

[Approval Request Comment]
Bug caused by (feature/regressing bug #): unknown
User impact if declined: some frames are not scrollable when they should be. this appears to affect a small percentage of websites.
Testing completed (on m-c, etc.): on m-c
Risk to taking this patch (and alternatives if risky): affects fennec only, pretty low risk.
String or IDL/UUID changes made by this patch: none
Attachment #753812 - Flags: approval-mozilla-beta?
Attachment #753812 - Flags: approval-mozilla-aurora?
Thanks for fixing this!
Verified works on Nexus 7 with Firefox Mobile nightly build.
Attachment #753812 - Flags: approval-mozilla-beta?
Attachment #753812 - Flags: approval-mozilla-beta+
Attachment #753812 - Flags: approval-mozilla-aurora?
Attachment #753812 - Flags: approval-mozilla-aurora+
Might be worth a relnote? Fixes a regression in 21 as part of Firefox 22.
relnote-firefox: --- → ?
Paul would you investigate if automating this issue is possible.
Flags: needinfo?(paul.feher)
Blocks: 878767
We will look into this, I've opened bug 878767 regarding this issue.
Flags: needinfo?(paul.feher)
You need to log in before you can comment on or make changes to this bug.