9805 - User notification of URL opening into new window required

Status: VERIFIED INVALID

(SeaMonkey :: UI Design, defect, P3)

Description

[Crysgem]

Given the unoptimized state of the current Win32 Mozilla builds, the slow
generation of the (presently bug-ridden) _New windows is to be expected.
(Those opening the linked URL in a new window)
However, the inexperienced user is likely to believe that the click-selection
was not processed until the window appears. The original window deigns to emit
no notification for our bedraggled user, to simply state that the action is
being processed (this design flaw is noted as shared among Ancestor 4.6 and
Enforcer 5.0, as well). As the beast is presently quite ponderous in the
production of the new windows (upon this, my overtasked machine, and all others
of it's speed class), the inexperienced and impatient user may come to believe
that the magic click did not work (horrors).
In turn, repeated clicks on _New links have the tendency to crash Mozilla (no
bug filed as yet, for 't'is not easily step-defined). This does not encourage
the casual tester.

Comment 1

[brendan-obsolete]

This isn't mine, no matter how hard I read its tortured prose!  Giving to
trudelle for further assignment.  It seems we aren't changing link color to the
"clicked-on, but not yet visited" color for all links?  Or maybe just for links
that target another window.

/be

Comment 2

[Crysgem]

<Californyisms>
OK, d00d, reed me straight: You got a link, something like
<A HRef="http://www.mozilla.org" Target="_New">Mozilla.org</A>,
right? Clickin' it opens the page, IN A NEW WINDOW. Track? That window takes,
like, FUR-EV-ER to appear. That's a performance problem, guy. And I'm not
scratchin' you over that. Problem is, even if that wind0w, like, --->ZIPPED into
view, the poor lame-ass lu53r wouldn't know the page and window were loading,
'cuz there's no indication of that (something that, maybe, should show up in the
status bar?)... THAT'S a design flaw.
</Californyisms>

My prose isn't "tortured"... well, in that, sadistic entities can't truly be
tortured by direct means, yes?

Oh, yes... you are correct. If a Target="_New" link is selected, it is not
always (ever, in my experience?) color-changed to indicate selection.

Comment 3

[brendan-obsolete]

Thanks for the translation (but I was born in Pittsburgh and grew up on the East
Coast, mostly)!

/be

Comment 4

[Peter Trudelle]

This should be split into at least two separate bug reports. For now let's say
that this orignal report refers to the feedback problem described in the
summary.  It has nothing to do with my team's work though, so I'm reassigning to
german to ensure that the desired behavior is specified.

Comment 5

[shuang (gone)]

Agreed with trudell. here are three things:
1. Page loading speed. All the teams are working on it, and German is not a
helper for that effort.
2. When page is loading, there should be feedback text in status areas to show
the progress. Don's team is working on that implemetation. However, I don't see
this is a "major" bug because it is not the real cause of the crash. Change the
state to normal.
3. A UI spec for this purpose is done but not detail enough for the polish.
German is responsible for updating the spec, but not till m16.

Comment 6

[german]

one way to solve this on windows is using the combined hour glass and pointer
cursor as soon as the user has activated the link and until the new window
opens. Opinions?

Comment 7

[Sean Richardson]

The combined hourglass-and-pointer indication has merit, and makes sense,
but is definitely not XP. An XP way of doing this, and if [reaches for
Clement Wood's Rhyming tome] I can expose the meaning that the original
reporter's prose chose to propose, what I think was being asked for here,
would be to maintain the visual indication of an Active link (default: red)
not for the length of time that the click is held on the Anchor, but until the
_New window actually makes its first visual appearance. Or at least at all.
Something like that.

Comment 8

[leger]

Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.

Comment 9

[Sean Richardson]

On second thought, keeping the link that launches a new window in its
"active" ALINK state won't show much if the link is from an IMG with no BORDER,
or anything else where the ALINK colour will not show. It may still be worth
doing anyway, but it wouldn't always give an indication.

Also, there is no reason why the combined hourglass-and-pointer cursor couldn't
be XP, even if it makes its first appearance on a platform in mozilla: it is
pretty self-explanatory.

Comment 10

[Brendan Eich [:brendan]]

Adding dep on XP cursor bug.

/be

Comment 11

[german]

Right, I don't think combinng two familiar cursors will create something alien,
even for those users who haven't seen this cursor on their platform yet. I think
it's clearly better than no feedback, or link color feedback which relies on
colors, and the presence of such colored elements, both of which are not
guaranteed or distinctive enough. I'd say we go with a combine pointer/hourglass
cursor. If we want to make the extra effort we can have the turning b/w wheel
cursor for the mac implementation only, and have the hourglass for both Win and
X. Re-assigning to Don's team to cost...

Comment 12

[Chris Waterson]

Add bug 25189 to dependencies: fixing 25189 should cause the link to be colored 
as soon as it is clicked (there are currently some problems handling mouse 
events in anchor tags).

N.B. that this bug fans out to other problems, as well, like raw time to open a 
new window. When we fix 25189, let's re-evaluate whether or not we should keep 
this bug around.

Comment 13

[Pierre Saslawsky]

You may want to close that bug as duplicate of bug 10491 from the same reporter.
Note that bug 10491 is currently marked as WONTFIX (should have been LATER 
maybe?).

Comment 14

[Jesse Ruderman]

How about opening the new window right away, instead of waiting until the page 
starts coming in?  That would take care of the user confusion problems, make it 
much easier to open a series of links each in new windows (see also bug 9274), 
and make mozilla act more like netscape 4.x.

See also bug 12056 for a related discussion of how new windows should be opened.

Comment 15

[Matthew T (active 1999-2002)]

Come on, this is 4xp. If you want to open an URL from
<http://out.the.back.of.siberia.ru/> into a new window, Mozilla doesn't wait for 
half an hour until that URL responds before opening the new window. It opens the 
new window straight away, and lets the user carry on as normal in their original 
window. Even if the server never sends anything to the new window, there will 
still be an error document to display (see bug 28586).

Any other solution would involve feedback in one window for something that was 
actually going to happen in another, and that would be absurd.

If simply the act of opening the new window is taking longer than about 0.5 
seconds (and it shouldn't), then show a standard `busy' (hourglass/wristwatch) 
cursor until the new window *does* open, and then revert to the ordinary cursor.

Comment 16

[Jesse Ruderman]

you're right, that problem has been fixed since i tested it :)

Comment 17

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 18

[Paul Chen]

nav triage team:

Uhh, is this bug still relevant after almost two years? marking nsbeta1-

Comment 19

[Jesse Ruderman]

Adding:
bug 49141 New window performance
bug 76408 progress notifications for _new, _blank go to original window

This bug is less of a problem than it was before, but it might still be a good 
idea to use the pointer+hourglass cursor as the new window opens (as discussed 
earlier in this bug).

Comment 20

[Blake Ross]

I don't really understand this bug.  It seems to be invalid at this point. 
Please summarize if you reopen.

Comment 21

[sairuh (rarely reading bugmail)]

v, unless we get more info.