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.

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

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

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

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.

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.

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?

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.

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

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.

Adding dep on XP cursor bug. /be

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

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.

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

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.

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.

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

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

nav triage team: Uhh, is this bug still relevant after almost two years? marking nsbeta1-

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

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

v, unless we get more info.