121209 - Hard to match error dialogs to "owning" tab

Status: NEW

(SeaMonkey :: Tabbed Browser, defect)

Description

[Hakon]

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.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 2

[Hakon]

Sorry, I didn't make myself clear. I was referring to a specific webmail service.
But that's not important. It was just in order to make an example. The thing I
meant was javascript alert and such alikes.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

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)

Comment 4

[Hakon]

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.

Comment 5

[timeless]

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...

Comment 6

[jag (Peter Annema)]

Well, there is a real problem here that needs to be addressed, changing the
summary to what I see as the basic issue.

Comment 7

[Peter Trudelle]

nsbeta1+ per ADT triage team.  Usability and possibly security issues here.  cc
marlon, mstoltz for UE input

Comment 8

[marlon bishop]

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.

Comment 9

[Jaime Rodriguez, Jr.]

nsbeta1- per ADT/Nav triage.

Comment 10

[Peter Trudelle]

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?

Comment 11

[Peter Trudelle]

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.

Comment 12

[marlon bishop]

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.

Comment 13

[timeless]

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.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

the real fix is of course not to have error-dialogs at all, i.e. fix bug 28586

Comment 15

[Hakon]

In reply to the comment above:
Yeah but we're not only talking about Mozilla's internal error messages, but
also about javascript alerts coming from the dhtml code.
As much as I understand that those can be very annoying sometimes, I do not
think that they should be replaced by a plain html page.

Comment 16

[m_mozilla]

this bug was mentioned in bug 123913 

    [RFE] tab-specific alerts are app-modal and should be tab-modal
    (need "sheets" widgets on non-MacOSX)

which depends on bug 123908

    tab-specific alerts are window-modal (in Mac OS X)
    and should be tab-modal

Some of the alternatives discussed here were mentioned as possible alternative
fixes for bug 123913. I just thought I'd repeat an observation made there as
relevant to this discussion.

It sounds like most of the talk here is concerned with

    I have multiple tabs open
    I want to only see alerts from the foreground tab
    I want notification when background tabs have pending alerts

The nature of solutions seem something like

    find a way to supress background alerts
    find a way to notify that they're pending

That sounds like it does the job for this bug. However, you might also want to
keep in mind the related class of bugs concerned with alert modality. If you've
got a javascript that throws alert after alert after alert, then you could
potentially be "locked" into that tab's content dismissing an endless stream of
javascript alert boxes. This bug doesn't address that problem (and I'm not
saying that it should). You might want to keep in mind this modality problem so
that whatever solution is implemented will be compatible with content-modal
alerts. On the other hand, if nobody is really looking at content-modal alerts
right now, then I suppose it's better to just fix this bug and burn the other
bridge when you get to it.

-matt

Comment 17

[Michael Lefevre]

*** Bug 151836 has been marked as a duplicate of this bug. ***

Comment 18

[Jon Henry]

*** Bug 215758 has been marked as a duplicate of this bug. ***

Comment 19

[Jon Henry]

*** Bug 195648 has been marked as a duplicate of this bug. ***

Comment 20

[Vedran Miletic]

retargeting

Comment 21

[Jesse Ruderman]

*** Bug 230847 has been marked as a duplicate of this bug. ***

Comment 22

[Dan]

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.

Comment 23

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Is this still an issue given that most common failures should now result in
error pages instead of dialogs?

Comment 24

[Daniel C]

(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.

Comment 25

[Anton P.]

(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.

Comment 26

[Cees T.]

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.

Comment 27

[Michal 'hramrach' Suchanek]

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.