878940 - Reflow-on-zoom should perform reflow and snap as one

Status: RESOLVED DUPLICATE of bug 878935

(Firefox for Android Graveyard :: Readability, defect)

Description

[Scott Johnson (:jwir3)]

One thing that would be nice is if we were able to somehow perform the reflow-on-zoom event (max line box width change + reflow) as well as the snapping to a particular scroll position. Currently, we have the problem where we maintain the position by finding a DOM Range before the reflow event, then finding this screen position after the reflow by finding where the screen position of this DOM Range is after the reflow takes place. 

Unfortunately, this requires that we first perform the reflow, then determine the scroll position. Because the reflow takes a long time relative to the painting, multiple paint events could happen prior to snap, causing us to paint at least once before we get our final position, causing a disconcerting repositioning situation for the user.

Comment 1

[Scott Johnson (:jwir3)]

I think there are two possible solutions to this problem:

1) If we could somehow precompute the scroll position before the reflow, we could immediately move the viewport to this new position and then trigger the reflow. This would still have two paint events, but it would be less disconcerting, as it would not re-snap after the zoom occurs. 

2) We could hold all painting after a reflow-on-zoom event is triggered, but prior to the reflow being completed.

Note that if we were to do part 1) it might be in concert with bug 64926 and bug 139832.
Also, part 2) should definitely be in concert with bug 878935, as this will make it clear to the user that the browser isn't 'hung', but performing the reflow.

Comment 2

[Scott Johnson (:jwir3)]

Looks like we're going to take option 2, which will be fixed now in bug 878935, so I'm marking as duplicate.