Currently, when we perform reflow-on-zoom, pages that have a large number (>2) of subdocuments (e.g. cnn.com articles) will take longer to reflow than pages that do not have this attribute. Because this causes problems with responsiveness, we should separate the reflow of each of these documents into individual events so that UI events can be processed in between each of these. Moreover, the root document should be reflown first, which will (hopefully) improve perceived performance in the majority of cases. I split this off from bug 836565, since it's easier to track as a separate bug.

This patch makes the processing of reflow-on-zoom (max line box width) changes asynchronous for sub-document viewers. The document viewer class maintains a static queue of events to be processed. When a new request for changing the max line box width comes in, if the max line box width requested is different from the current max line box width for a given document viewer/pres shell, then it will enqueue a new request to change the max line box width for this document viewer. The first request for a given document is always processed immediately, and then this function dispatches the next request in the queue to the main thread, to be processed asynchronously.

Also, I'm in the process of writing a robocop test for reflow-on-zoom, but I'll post it as a separate patch.

Do we still want this? (I recall some suggestion that we didn't, but I'm not sure.)

(In reply to David Baron [:dbaron] (needinfo? me) from comment #3) > Do we still want this? (I recall some suggestion that we didn't, but I'm not > sure.) I think we can probably skip this. It looks like reflow-on-zoom is performing fairly well without it, so we should maybe avoid adding the complexity.

Comment on attachment 752497 [details] [diff] [review] b870788 ok, cancelling review, then

Mass change to move Firefox for Android::Readability bugs to block bug 1129033. Filter on readability-mass-move.

This code was removed.