User notification of URL opening into new window required

VERIFIED INVALID

Status

defect
P3
normal
VERIFIED INVALID
20 years ago
5 years ago

People

(Reporter: Crysgem, Assigned: vishy)

Tracking

({perf})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
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.
Assignee: brendan → trudelle

Comment 1

20 years ago
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

20 years ago
<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

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

/be

Updated

20 years ago
Assignee: trudelle → german

Comment 4

20 years ago
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.

Updated

20 years ago
Whiteboard: [Perf]

Updated

20 years ago
Severity: major → normal
Status: NEW → ASSIGNED
Target Milestone: M16

Comment 5

20 years ago
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

20 years ago
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

20 years ago
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.

Updated

20 years ago
Keywords: perf

Comment 8

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

Comment 9

20 years ago
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.
Depends on: 9665
Adding dep on XP cursor bug.

/be

Updated

20 years ago
Assignee: german → don
Status: ASSIGNED → NEW

Comment 11

20 years ago
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

20 years ago
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.
Depends on: 25189

Updated

20 years ago
Whiteboard: [Perf]

Comment 13

20 years ago
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

19 years ago
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.
Keywords: 4xp
OS: Windows 98 → All
Hardware: PC → All

Comment 16

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

Updated

19 years ago
Target Milestone: M16 → Future
(Assignee)

Comment 17

19 years ago
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy

Comment 18

18 years ago
nav triage team:

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

Comment 19

18 years ago
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).
Depends on: 49141, 76408

Comment 20

17 years ago
I don't really understand this bug.  It seems to be invalid at this point. 
Please summarize if you reopen.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Component: XP Miscellany → XP Apps: GUI Features
QA Contact: brendan → sairuh
Resolution: --- → INVALID
v, unless we get more info.
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite

Updated

11 years ago
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.