Open Bug 121209 Opened 18 years ago Updated 7 years ago
Hard to match error dialogs to "owning" tab
I don't think that popup windows (like notifications and so) should show other than when you are in the respective tab. Here's an example: I have several tabs open with mail composition pages. I submit some of the mails simultaneously. Then I get a popup notification saying: "the mail wasn't sent due to some error". But then I don't know which mail wasn't sent. If it had been a layer of it's own tab, then it wouldn't have been any problem. The same thing about the pasword manager and login popups.
We don't support loading mailnews (or any other of the products) in tabs. That's just a hack and basically use at your own risk. This is very likely a wontfix but I will let jag decide for sure.
Ah okay, that's slightly different, but I still think this is a wontfix. The modals contain useful information. If I have my tabs set to load in background, I will want to know what is going on in other tabs. If it can't connect, I'd like to know when it happens. I see your point, but I dunno. It doesn't seem right to me. I will confirm this though as an RFE (no dupes found)
Severity: minor → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Maybe a "taskbar notification" for tabs could be an idea. Like in MS Windows, the tabs could have a blue highlight flashing (or something else, it doesn't have to be that drastic) when there's a new alert.
somewhere out there are a few rfes which might be of interest, one would put errors into the sidebar/jsconsole, and another would make errors appear inline to the page. ideally the fix for all of them will rely on one implementation of an error service...
Well, there is a real problem here that needs to be addressed, changing the summary to what I see as the basic issue.
Summary: Popup notifications shouldn't be cross-tab → Hard to match error dialogs to "owning" tab
Target Milestone: --- → mozilla1.0
nsbeta1+ per ADT triage team. Usability and possibly security issues here. cc marlon, mstoltz for UE input
how/why would this be any different than receiving errors from a window which is in the background? if it is different, then maybe one idea is that we could provide an error icon/notification in the tab area which shows that the page in this tab requires attention before it's process can proceed.
Marlon, I guess it is equivalent, except that background windows might be at least partially visible, whereas pages on background tabs are not. Is there a bug for the generic issue of not being able to associate the popup/error/window with the spawning web page?
Target Milestone: mozilla1.0 → mozilla1.0.1
On second thought, it is possible to determine which window spawned the popup/error/login window, by cycling between the windows. The owner is the one that it appears in front of when you activate it. There is no equivalent method for tabs. This is really a defect, not an enhancement request.
Severity: enhancement → normal
yes i see what you are saying. so it seems that some sort of alert notification should take place in the tab area. we should replace the tab proxy/favicon with a mini alert icon. Then the alert might need a shortcut to bring the troublesome tab to the foreground.
give the tab a style and let the skin author decide how to handle it, but if i were the skin author, i'd color the tab background. whacking the icon would be bad.
the real fix is of course not to have error-dialogs at all, i.e. fix bug 28586
*** Bug 151836 has been marked as a duplicate of this bug. ***
*** Bug 215758 has been marked as a duplicate of this bug. ***
*** Bug 195648 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0.1 → Future
*** Bug 230847 has been marked as a duplicate of this bug. ***
I think something similar to the taskbar blink you get when an app requests focus in Windows would be ideal, not necessarily animated for accessibility sake, but definitely highlighted in some way.. This would be such a big usability improvement IMHO and should remove all confusion as to which tab a dialog box was initiated from.
Is this still an issue given that most common failures should now result in error pages instead of dialogs?
(In reply to comment #23) > Is this still an issue given that most common failures should now result in > error pages instead of dialogs? Yes; note the word 'most' in you comment. There are still a fair few alert errors. Also, script alerts.
(In reply to comment #23) > Is this still an issue given that most common failures should now result in > error pages instead of dialogs? A specific example of an application-generated error dialog which is not an error page is the "Security error: Domain Name Mismatch" modal. This is necessarily a dialog rather than a page because user interaction is required. Hence this bug is still relevant.
I propose replacing the browser generated, page related, error dialogs with red information bars; akin to IE7's blocked content notification. Warnings could be orange, and information yellow or blue.
Note there is also the basic auth dialog and "Repost data?" dialog. I think repost switches to the tab in question so it might be apparent what is reposted but hides the content you were viewing. However, most dialogs (especially SSL errors) do not so you don't have any idea what page they relate to. The error pages (for HTTP errors) change the tab icon into an exclamation mark inside a yellow triangle. I am not sure if this just a style hint rendered this way by the default skin or it is hardcoded. However, I suggest that all other errors should render this way, queries that have to be answered for the main page to load (basic auth, cookie queries, ssl errors, repost) should yield a query page with a distinct icon (perhaps a question tag on a red background). Note that rendering repost as a query page would make it apparent what is reposted and even make it possible skip easily to an earlier page in the history that does not have to be reposted. Errors and queries that are related only to part of the page (such as an image or subframe) should result in an info bar and the rest of the page should continue loading. This is already implemented in noscript and would solve Bug 328052. Note that rendering the info bar at the bottom of the page is a great performance win as the page does not have to be completely redrawn when the bar appears or disappears. I is a sad fact that Firefox (and even IE) redraw this slowly even on relatively modern hardware.
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser
Target Milestone: Future → ---
You need to log in before you can comment on or make changes to this bug.