Closed Bug 860489 Opened 11 years ago Closed 6 years ago

Inspect ways to optimize page-swiping responsiveness and logic

Categories

(Core :: Widget: Cocoa, enhancement, P5)

x86
macOS
enhancement

Tracking

()

RESOLVED FIXED

People

(Reporter: beingalink, Unassigned)

References

Details

(Whiteboard: tpi:+)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130410 Firefox/23.0
Build ID: 20130410065939

Steps to reproduce:

Navigating the History with swipe gestures on the trackpad.


Actual results:

The duration it needs moving the two fingers on the trackpad to complete the animated page switch is longer than with safari. This also seems to depend on the page content: On http://ie.microsoft.com/testdrive/Performance/Bubbles/ it is impossible for me to navigate away from the page using the swipe gesture (the trackpad isn't wide enough).

I'm on a Macbook Core2Duo 2Ghz, NVIDIA GeForce 9400M 256 MB, 4 GB RAM


Expected results:

Navigating with the swipe gesture should work the same as with Safari.
Component: Untriaged → Widget: Cocoa
Depends on: 678392
Product: Firefox → Core
Version: 23 Branch → Trunk
Blocks: 678392
No longer depends on: 678392
No longer blocks: 678392
Depends on: 678392
Depends on: history-swipe
> The duration it needs moving the two fingers on the trackpad to
> complete the animated page switch is longer than with safari.

This is very unclear.  What do you mean by "duration"?

Is it the time the operation takes?

Or (much more likely) is it the distance you have to move your fingers
when swiping?
Sorry. Yes, it's the distance which the fingers have to move over the trackpad.
I'm unable to reproduce this. We seem to be switching between pages more or less at the same horizontal point as Safari when the fingers are released. Is there anything in particular that could be causing this on your system?
OK, I tested that some more. If I do the swipe slowly so that it's like dragging the page out of the screen, it seems to work. But I was used to do the swipe quickly with "drive" so it's like the page frame gets a "kick" with enough "energy" so it slides out of the screen. This is how I do it on Safari. Perhaps this bug is completely misleading and it's rather about a missing feature like recognizing swipe speed or sth. like that (not sure).

On a different note: Is it expected behavior that with having browser.snapshots.limit set to 0, the swipe gesture is completely disabled now? It used to trigger forward/backward navigation (of course without animation).
> On a different note: ...

See bug 860779.
I can verify this is an issue. Though some clarification:

The problem really is three things:

  A. Swiping responsiveness is lower than Safari's. Meaning on Safari you are not required to move your fingers as much in order to go the same distance. This makes Safari's animation seem faster.

  B. We don't take into account the momentum of a page swipe as much as Safari does. In Safari, if you want to quickly go back, you can move your fingers over about 3/4 of an inch and it will *quickly* swipe over if you moved your fingers very rapidly. If in Safari, you go the same distance, but slowly, it will not complete. In contrast, we seem to require your fingers to go a farther distance regardless of how fast someone swipes over.

  C. While pages are loading it becomes increasingly difficult to complete a swipe gesture. I believe (but can't yet verify), that this happens when a page reflows it's layout. Whenever that happens the entire page jumps back to place. Safari seems to solve this problem by simply *not* allowing the swipe gesture at all until it can perform the swipe gesture reliably.

Really this bug is quite complex and will require quite a bit of logic to decide whether or not to start/finish swipes, etc. Right now we seem to have fairly basic swiping logic.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: gesture for swipe animation takes too long → Inspect ways to optimize page-swiping responsiveness and logic
Depends on: 1382560
No longer depends on: 1382560
(In reply to Josiah Bruner [:JosiahOne] (needinfo for responses) from comment #6)

> Really this bug is quite complex and will require quite a bit of logic to
> decide whether or not to start/finish swipes, etc. Right now we seem to have
> fairly basic swiping logic.

This feels like a feature enhancement.
Severity: normal → enhancement
Priority: -- → P5
Whiteboard: tpi:+
Some improvements were made in bug 860493 to the responsiveness of page swipes. We also switched to using arrows instead of page snapshots as swipe animations/indicators. Closing this bug for now, but please reopen (and give detail) if this continues to be an issue.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.