Closed
Bug 806657
Opened 12 years ago
Closed 12 years ago
when adding a new Google calendar, no feedback to user after hitting "save"
Categories
(Firefox OS Graveyard :: Gaia::Calendar, defect, P3)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 810153
People
(Reporter: dietrich, Unassigned)
Details
(Whiteboard: [mentor=jlal@mozilla.com][LOE:S])
I hit save about 5 times, because nothing happened. Then the app surprisingly closed the pane without any user interaction, and started loading calendars.
Is this a polish?
as I test, after I press "save"
the screen will return to main page and see it's loading
Comment 2•12 years ago
|
||
qawanted: how long is the delay between save and returning the main page?
Keywords: qawanted
Updated•12 years ago
|
OS: Mac OS X → Gonk (Firefox OS)
QA Contact: jsmith
Hardware: x86 → ARM
Reporter | ||
Comment 3•12 years ago
|
||
I think it's variable, depending on network+server response time.
The UI stays responsive instead of blocking on that variability. However, the whole pane should close, instead of staying open until the operation completes. Right idea, implemented in the wrong part of the flow.
Some possible solutions:
* Pop up a progress overlay, preventing any user action until the operations complete. This blocks the user, but would reduce confusion - "i finished, but my calendar items aren't here. did it work?!"
* Close the UI immediately, putting the user back in the main view. Their calendar items fill in. Possible confusion if slow network - "i finished, but my calendar items aren't here. did it work?!"
* The above, but with a progress indicator somewhere in the calendar primary UI.
Comment 4•12 years ago
|
||
Removing qawanted mainly since I think Dietrich answered the question in detail.
Updated•12 years ago
|
blocking-basecamp: ? → -
Comment 5•12 years ago
|
||
This absolutely should make it into v1, in fact we have "in-progress" css classes added/removed from the containers as is so this could be a pure-styling fix depending on how we want to handle it.
Keep in mind the process of finding their calendars is much quicker then syncing all the events.
Both are totally separate requests/processes so we have quite a bit of flexibility here.
However I don't think waiting until the full sync has completed is a good idea, even with maximum optimization event sync will take a good deal of time on slow connection.
--
This is a good mentored bug too, not too hard but delivers critical value.
blocking-basecamp: - → ---
Priority: -- → P3
Whiteboard: [mentor=jlal@mozilla.com][LOE:S]
Comment 6•12 years ago
|
||
Did you mean to renom the bug?
Comment 7•12 years ago
|
||
Hello James,
I can work on this. i have gaia setup to work on B2G Desktop on OSX.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•