Page MenuHomePhabricator

Flash of Unstyled Content when loading bookmarks in Android App
Closed, ResolvedPublic

Description

Loading a bookmark loads the html without js/css, which load quite slowly. Leads to unstyled bad looking plain-text for about 10-15s on my device.


Version: 1.0.0 (Android)
Severity: normal

Details

Reference
bz33022

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 12:05 AM
bzimport set Reference to bz33022.

Yeah, this is a side effect of how the caching currently works; basically there's a low-level caching plugin which fetches the original page content exactly, and then the JS comes and does fixups to the styles and links. Eww?

Saving the fixed content instead would help.

Is that even possible? ('saving the fixed content')? Save final serialized DOM
tree structure, perhaps? Can DOM trees even be serialized?

philinje wrote:

I saw this behavior when hitting the back button, but the page would never load fully and the app crashed (this was reported as bug 32998).

brion added a comment.Dec 15 2011, 7:07 PM

I worked around this by hiding the iframe during initial stages of load, and showing it again after the styles had been replaced.

commit 6457d1ce676996099cf30544d7db7af33b3a23b8

bug 32998 still remains however.

Not sure if this is 'good enough' - the content area blanks out for about 15-20 seconds on my phone when I load a bookmark. Also happens when I simply add a bookmark. Is there a 'proper' fix?

Not sure if this is 'good enough' - the content area blanks out for about 15-20 seconds on my phone when I load a bookmark. Also happens when I simply add a bookmark. Is there a 'proper' fix?

brion added a comment.Dec 15 2011, 8:21 PM

This no longer happens when bookmarking on my cachework branch, as the pages are loaded through urlcache to begin with now. Can you build that locally and test how long it takes to load things for you?

https://github.com/brion/Wikipedia/tree/cachework

This does leave us waiting for the entire HTML to load, but once one set of styles has been cached they should stay pretty well for a while so won't cause additional delays beyond the HTML for second page and beyond.

Just tested it, seems to be the same (15s for India article from bookmark for both master and cachework). Seems to vary by article size - Adulasion Horse article takes only 7s (on both) for example.

brion added a comment.Dec 15 2011, 9:08 PM

Darn... may be that the only good way to handle this is to modify the pages before caching -- that means tweaking the cache... a lot...

brion added a comment.Dec 16 2011, 6:30 PM

I'm going to go ahead and close this out and break out the slow loading issue to bug 33197 -- I've made that a blocker on 1.1 release and added a note that changing how the caching works so we save the already fixed-up version should resolve the slowness without reintroducing flash-of-unstyled-content.