Last modified: 2014-10-15 18:15:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T70845, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 68845 - Safari on iPad crashes when viewing large articles?
Safari on iPad crashes when viewing large articles?
Status: RESOLVED WORKSFORME
Product: MobileFrontend
Classification: Unclassified
stable (Other open bugs)
unspecified
Tablet PC All
: Unprioritized normal
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-30 08:14 UTC by deanator71
Modified: 2014-10-15 18:15 UTC (History)
8 users (show)

See Also:
Web browser: Apple Safari
Mobile Platform: iOS 7.x
Assignee Huggle Beta Tester: ---


Attachments

Description deanator71 2014-07-30 08:14:00 UTC
When viewing an article as large as https://en.m.wikipedia.org/wiki/Fukushima_Daiichi_nuclear_disaster, when I click one of the table of contents links, the screen turns white and my Safari crashes. It may also crash my iPad as well. Is MobileFrontend using way too much memory for large pages? It seems to be scrolling through the long page by setting scrollTop to something else that is causing the crash. The iPad, I think, is using a lot of memory when I view such a long page. I do not think it is MobileFrontend's issue. It might just be providing safari some awful lot of content that tells safari to use a hell of a lot of memory. It could also be the images, have you set any custom fonts? You could also split the page into sections so the user reads one section, clicks on a link that goes to the next section to continue reading the article, if you guys cannot reproduce this. You could also improve performance by loading content when the user scrolls down to them, and removing content from the page when is not viewed for some time. Can you check if this memory issue happens on the iPhone as well?
Comment 1 Andre Klapper 2014-07-30 09:45:36 UTC
Thanks for taking the time to report this!

Which Safari version is this about and which iPad version?
(For general information, see https://www.mediawiki.org/wiki/How_to_report_a_bug )
Comment 2 deanator71 2014-07-30 10:36:26 UTC
On iOS 7.1.2 with the iPad 4
Comment 3 Ryan Kaldari 2014-07-30 17:36:37 UTC
No luck so far reproducing the crash, but following the TOC links is definitely slow on en.wiki on iPad. The links are just plain anchor links, although they do have an eventLogging action bound to them.
Comment 4 Bingle 2014-07-31 18:10:02 UTC
Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/qc5BQmBq
Comment 5 Juliusz Gonera 2014-08-14 23:33:14 UTC
Reproduced on iPad retina.
Comment 6 Juliusz Gonera 2014-08-14 23:35:22 UTC
Does not happen every time though...
Comment 7 Juliusz Gonera 2014-08-15 00:13:04 UTC
My guess is that this is a iOS Safari bug. It seems to crash only now and then (actually I haven't been able to reproduce more than once) and scrolling through the page seems to always work. It might be related to Safari rendering the content only when the user scrolls to it. Possibly there is a bug that causes it to crash if we suddenly scroll by a huge distance.

I couldn't reproduce that on a simple page with a lot of lorem ipsum and a link scrolling all the way to the bottom. It's possible that it's a combination of scrolling and CSS or JS that triggers the bug. http://stackoverflow.com/questions/11831429/mobile-safari-on-ios-crashes-on-big-pages suggests that transitions might cause it.

I'd watch this bug and see if it happens more often. If it does, we should find a workaround.
Comment 8 Jon 2014-09-17 18:32:36 UTC
It's in stable now so changing component.
Anymore instances of this?
Comment 9 Jon 2014-10-08 19:03:51 UTC
Can anyone reproduce this?
Comment 10 Jon 2014-10-15 18:15:47 UTC
Please reopen if this is still being experienced.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links