Connection problem causes complete failure of XHR changes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
LAZR Javascript Library |
Triaged
|
Low
|
Unassigned |
Bug Description
1. Go to a bug report, e.g. <https:/
2. Click the button for editing the description.
3. Disconnect from the Internet, e.g. by moving a bit too far away from the wireless access point.
4. Change the bug description.
5. Click the confirm button.
6. Reconnect to the Internet.
What happens:
* A red border appears around the description field.
* A spinner appears forever.
* There is no explanation of what went wrong, and no possibility of correcting the problem without careful copying and reloading and pasting.
John Lea and I brainstormed five possible design solutions for this problem, and discussed the pros and cons of each. We had in mind that lazr-js applications will differ in design, so requiring applications to embed connection status in individual pages would be fiddly. We also recognized that eventually, some applications will want to support offline use (like Gmail is increasingly doing, for example), so anything that blocks you from further work as long as you are offline would run counter to this.
We concluded that this should happen instead:
* A placard should slide down from the top of the viewport (similar to the placards Firefox uses for missing plug-ins or blocked popup windows), saying something like "Connection problem". If the application is capable of replaying XHR transactions, this should be followed by something like "— will try reconnecting in 60 seconds".
* If the application is capable of replaying XHR transactions, the transaction should be retried when the timer reaches zero.
* If the application is not capable of replaying XHR transactions, the field should flash red because the changes weren't saved, and any cancel and confirm buttons should return.
description: | updated |
Changed in lazr-js: | |
status: | New → Triaged |
importance: | Undecided → High |
To a large degree, handling explicit submits when offline is a browser issue at core, not a js library issue. (For starters, how do you tell 'locally offline' vs 'server dead' etc).
Anyhow, for now, I don't think this is in our roadmap, downgrading to low.