Closed
Bug 965354
Opened 12 years ago
Closed 11 years ago
Don't display error dialog on aborted requests
Categories
(Tree Management Graveyard :: OrangeFactor, defect)
Tree Management Graveyard
OrangeFactor
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: mcote, Unassigned)
Details
Attachments
(1 file, 3 obsolete files)
|
24.93 KB,
patch
|
mcote
:
review+
|
Details | Diff | Splinter Review |
I believe that an error dialog is being displayed if an AJAX request is aborted, e.g. if you quickly switch to another page while the first one is still loading some data. Since this is the result of an intentional user action, we shouldn't display errors when AJAX requests are aborted, only when there is a server error.
Comment 1•12 years ago
|
||
Attachment #8368636 -
Flags: review?(mcote)
| Reporter | ||
Comment 2•12 years ago
|
||
Comment on attachment 8368636 [details] [diff] [review]
Loader added on ajax loading
Review of attachment 8368636 [details] [diff] [review]:
-----------------------------------------------------------------
Looks like you forgot to include the image (do "hg add <path to image>" before doing the hg diff).
Attachment #8368636 -
Flags: review?(mcote) → review-
Comment 3•12 years ago
|
||
Attachment #8368636 -
Attachment is obsolete: true
Attachment #8368688 -
Flags: review?(mcote)
| Reporter | ||
Comment 4•12 years ago
|
||
Comment on attachment 8368688 [details] [diff] [review]
Loader added on ajax loading
Review of attachment 8368688 [details] [diff] [review]:
-----------------------------------------------------------------
So there are two problems here. First, it didn't actually work for me at all, because the .ajaxStart() call occurred after the displayOverview() call, which starts the AJAX calls. It seems that add the ajaxStart() handler after an AJAX call has been started doesn't work for the current or future AJAX calls either. Did it really work for you?
Secondly, I would prefer a less obtrusive loader, maybe in the corner or somewhere else out of the way. Since there are several AJAX calls in one page load, you shouldn't obscure the screen when there is useful data being shown, e.g. after the graph loads, while it's doing another AJAX call to get some data for a secondary table display.
Attachment #8368688 -
Flags: review?(mcote) → review-
Comment 5•12 years ago
|
||
Attachment #8368688 -
Attachment is obsolete: true
Attachment #8370117 -
Flags: review?(mcote)
Comment 6•12 years ago
|
||
Attachment #8370117 -
Attachment is obsolete: true
Attachment #8370117 -
Flags: review?(mcote)
Updated•12 years ago
|
Attachment #8370154 -
Flags: review?(mcote)
| Reporter | ||
Comment 7•12 years ago
|
||
Comment on attachment 8370154 [details] [diff] [review]
Loader added on ajax loading
Review of attachment 8370154 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good! I have a few comments, which can be fixed when I commit your patch, although I'd like an answer to the last one in particular.
::: html/scripts/woo.main.js
@@ +273,1 @@
> displayOverview();
I think I would put in an extra blank line above, for clarity.
@@ +275,5 @@
> // Initialize per-page controls (relies on global controls being loaded).
> for (var i = 0; i < menus.length; i++) {
> $(menus[i]).attr('href', PageLoader.buildUrl($(menus[i]).attr('id').slice(4), {}));
> }
> +
Don't need the extra space here.
::: html/style/main.css
@@ +513,5 @@
> +.loader {
> + position: absolute;
> + left: 96%;
> + top: 7%;
> + position: fixed;
Why are there two "position" attributes?
Attachment #8370154 -
Flags: review?(mcote) → review+
| Assignee | ||
Updated•11 years ago
|
Product: Testing → Tree Management
Comment 8•11 years ago
|
||
Wontfix in favour of OrangeFactor v2 which will consume Treeherder's API, and likely be written from scratch.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Tree Management → Tree Management Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•