User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20171212094056 Steps to reproduce: Use firefox in general, but for more precise instance, switch tabs with e10s disabled. Actual results: When accessibility/base/NotificationController.cpp's WillRefresh is called, it only processes events for the document the NotificationController is attached to. To fix bug 1260598 (and then bug 1425932) , we made it to process the parent document beforehand, so that events get delivered in parent then child order. Expected results: Alexander Surkov would rather register only one observer, whose WillRefresh will just go through the whole documents tree, to be able to deliver all events in a known-to-be-good order.
My concern, however, is that browsing the whole document tree could be expensive. I have seen even heavy websites contain only like 20 documents, but e.g. on leboncoin.fr (very famous in France), I'm getting dozens of documents, it seems to actually increase while browsing, easily reaching hundreds of documents and counting :/ On the other hand WillRefresh calls don't increase accordingly, it remains at the same load level, meaning only a constant few of those documents are actually requesting ScheduleProcessing, and thus the webpage remains usable. Browsing the whole documents tree on each WillRefresh call would however make the browsing more and more sluggish.
(to trigger the increase dozen by dozen, on the front leboncoin.fr webpage, press page down until the end, then press page up a couple times, then down again to the end, then up again, then down again, etc. on each up/down iteration a dozen more documents appear.)
Component: Untriaged → Disability Access APIs
Product: Firefox → Core
You need to log in before you can comment on or make changes to this bug.