Closed Bug 828367 Opened 9 years ago Closed 9 years ago

Attempting to pan an iframe alternately scrolls the page and the iframe.

Categories

(Firefox OS Graveyard :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(blocking-basecamp:+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed)

RESOLVED FIXED
B2G C4 (2jan on)
blocking-basecamp +
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 --- fixed

People

(Reporter: jdm, Assigned: schien)

References

Details

Attachments

(1 file, 2 obsolete files)

STR:
1. visit cbc.ca in the browser
2. find the pannable schedule on the right side of the page
3. pan partway down it, lift finger
4. pan partway down it again

Expected:
The schedule continues to pan.

Actual:
The rest of the page is panned instead. This alternating iframe/page scrolling happens regardless of pan direction.

bb? to get it on the radar; I suspect the instance of panning iframes is not very high on the mobile web, but I don't really know anything about it.
is this a duplicate of 827715?
(In reply to Doug Turner (:dougt) from comment #1)
> is this a duplicate of 827715?
no, the WIP patch for 827715 doesn't help on this bug, but the root cause should be inside the APZC.
I'll take further investigation on this bug.
Assignee: nobody → schien
Comment on attachment 699843 [details] [diff] [review]
Attempt to scroll a cross-document parent frame when no other pannable target can be found.

Wrong bug.
Attachment #699843 - Attachment is obsolete: true
blocking-basecamp: ? → +
Duplicate of this bug: 828885
The bug is in BrowserElementScrolling.js, the first touchmove event we received is always contain the same screenX and screenY as touchstart. Therefore, we'll not perform scrolling since the moving distance is too small. However, the moving distance will continue to accumulate after the change made for bug 823619 and that's why we can have a successful scrolling for the next touchstart-touchmove transaction.

So, the defect I discovered in https://bugzilla.mozilla.org/show_bug.cgi?id=823619#c106 is severe than I thought before.
(In reply to Josh Matthews [:jdm] from comment #0)
> bb? to get it on the radar; I suspect the instance of panning iframes is not
> very high on the mobile web, but I don't really know anything about it.

This affects the Firefox OS support site. I think this is something we have to fix for release. http://people.mozilla.org/~mverdi/video/sumo-scroll.webm
Sure, I'm working on a patch for this bug. :)
If BES found the panning distance is too small to scroll, BES need to notify APZC and APZC need to keep delaying the panning procedure.
Attachment #700533 - Flags: review?(jones.chris.g)
Comment on attachment 700533 [details] [diff] [review]
Bug 828367 - APZC should not perform scrolling if BES detects panning distance is too small.

Oh no, wrong patch! :)
Attachment #700533 - Flags: review?(jones.chris.g)
Comment on attachment 700581 [details] [diff] [review]
Bug 828367 - APZC should not perform scrolling if BES detects panning distance is too small.

Works great and looks correct.

The patch seems to be based on bug 827715,but I tested it on its own.  It doesn't fix bug 827715 as-is.
Attachment #700581 - Flags: review?(jones.chris.g) → review+
(In reply to Chris Jones [:cjones] [:warhammer] from comment #13)
> Comment on attachment 700581 [details] [diff] [review]
> Bug 828367 - APZC should not perform scrolling if BES detects panning
> distance is too small.
> 
> Works great and looks correct.
> 
> The patch seems to be based on bug 827715,but I tested it on its own.  It
> doesn't fix bug 827715 as-is.
This patch should be independent from bug 827715. :)
Keywords: checkin-needed
Landed on inbound and b2g18, so we can close this one.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Duplicate of this bug: 829336
Target Milestone: --- → B2G C4 (2jan on)
Duplicate of this bug: 828885
You need to log in before you can comment on or make changes to this bug.