Closed Bug 1071367 Opened 8 years ago Closed 8 years ago

Composition bounds for root content scroll frame in OS X ignores height of chrome

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla35

People

(Reporter: kats, Assigned: kats)

References

Details

Attachments

(1 file, 1 obsolete file)

Start nightly, set layers.async-pan-zoom.enabled and layers.draw-borders to true from about:config, and load a scrollable page (e.g. http://planet.mozilla.org/). Scroll down and observe that there is a purple border that starts at the top of the chrome and stops 79 pixels from the bottom of the window (79 pixels being the height of the chrome for me). This purple border is the composition bounds of the scrollable content document, but it has a top-left of (0,0) instead of (0,79).

This also means that using the two-finger trackpad scroll gesture doesn't work while the mouse cursor is in the bottom 79 pixels of the content (outside the purple rect).
This is a regression from bug 1043644 part 1, which switched to using the content viewer bounds instead of the frame bounds to fix behaviour on metro. Switching back to the frame bounds fixes the problem. It also fixes the problem where, with APZC enabled, the displayport is offset from tile boundaries by the height of the chrome.
Blocks: 1043644
Attached patch Real patchSplinter Review
Assignee: nobody → bugmail.mozilla
Attachment #8493489 - Attachment is obsolete: true
Attachment #8493806 - Flags: review?(tnikkel)
Comment on attachment 8493806 [details] [diff] [review]
Real patch

Yeah, that makes sense. Wouldn't expect content viewer bounds to have the right offset.
Attachment #8493806 - Flags: review?(tnikkel) → review+
https://hg.mozilla.org/mozilla-central/rev/8abfd1252969
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.