Invoke VE from iOS Safari on tablet,
Make changes to page in VE
Open second tab, load another website,
Switch back to tab with VE instance, page is reloaded, and changes are lost
Description
Description
Details
Details
- Reference
- bz68017
Event Timeline
Comment Actions
This is "normal" behaviour from Safari, but we need to investigate if we can prevent (or at least discourage) it somehow.
Comment Actions
Yep, I know this one might be difficult but it obviously makes doing references on mobile basically impossible. glad to see we're prioritizing this.
Comment Actions
Unfortunately, on investigation, this is something that we can't avoid; it's the built-in behaviour of Safari that we have no control over, sadly. Marking as "WONTFIX" but it's more "CANTFIX".
Comment Actions
This might not be able to resolved as the bug is written (stop safari from reloading) but the current experience for the user in unacceptable. We need a solution. possibly server side drafts or using localstorage on the device. Feel free to rewrite the bug, but we can't ignore this issue.
Comment Actions
(In reply to Jared Zimmerman (WMF) from comment #4)
This might not be able to resolved as the bug is written (stop safari from
reloading) but the current experience for the user in unacceptable. We need
a solution. possibly server side drafts or using localstorage on the device.
Feel free to rewrite the bug, but we can't ignore this issue.
Well, this is what Apple wants to happen. We already say to the browser "don't just close me". Apple has decided in its wisdom to ignore that. We can try to take steps to make it less-terrible, but the underlying issue can't be fixed except upstream…
Comment Actions
From what I remember of our testing, it's the same, controlling for RAM size. Mostly this is a performance / resource use issue.
Comment Actions
Similar, but not 100% reproducible, I think it depends on how much memory the tab is using, which probably corresponds to the size of the article you're editing. chrome might also just try to keep more than one tab alive concurrently
Comment Actions
A long term solution would be to store editing state in localStorage. I think there's an existing bug for that.
The best we can do at the moment is warn the user. The most likely time they'll switch is if they're using Citoid, and they go to get a URL to copy.
Comment Actions
Also the beahviour is the same on both devices: the tab is only expunged when the device runs out of memory.
Comment Actions
I don't know, what is the difference between VisualEditor-Performance and Performance, but Performance is used in similar VE issues and here is missing
Comment Actions
Performance-Team is for any task worked on by the performance team. (Known issues in software we maintain, and improvements anywhere else if we're involved.)
Performance-Team is a generic tag for other projects to track known problems causing bad performance. (Not usually improvements/enhancements.) In addition, projects with their own subproject or workboard column for performance, normally don't also tag with Performance (similar to Tech Debt). I've untagged this and others with VisualEditor-Performance.
Comment Actions
Having poked about with this both locally and in production, I think we can declare this done alongside T57370. Assigning to Ed because he did a lot of the work, both recently and over the past few years.