Closed
Bug 78361
Opened 24 years ago
Closed 13 years ago
`spinning' cursor during loading should not be overridden by html.css
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
INVALID
People
(Reporter: mpt, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [p-ie/windows] [p-ie/mac])
Attachments
(1 obsolete file)
Build: 2001043008, Mac OS 9.1
To reproduce:
* Go to a Web page which contains some links and text, such as
<http://mozilla.org/>.
* In the address field, enter an address which does not exist but which will
take a long time to resolve, such as <http://radionz.co.nz/>. Press Enter.
* While waiting for the DNS request, move the cursor around the current page.
What you see:
* The cursor varies between the `spinning' cursor, and the text cursor (for
text), the pointer cursor (for links).
What you should see:
* The `spinning' cursor should apply no matter what you point at.
Comment 1•24 years ago
|
||
Uh, why? Dragging over the text will still select it, clicking on the link
will still follow it (or if it doesn't now, it will with hyatt's frame patch),
so why don't we want the appropriate feedback? Anyways, work was done
specifically to ensure that the cursor did change, so if we're going back to
this behavior it should be mac-only. -> pchen, but the docshell guys
(specifically adam) should probably take this, since I think he did the last
patch.
Assignee: blakeross → pchen
Reporter | ||
Comment 2•24 years ago
|
||
What I'm asking for is how Internet Explorer 5.0 on Windows behaves, so, uh ...
removing pp for reconsideration.
The point of the pointer-and-hourglass (or pointer-and-beachball) cursor is to
say `yes, you can still click or drag, but be warned that what's under the
cursor might change at any moment, so your click or drag might not have the
desired effect'. This is true whether or not you're over a link, and whether or
not you're over selectable text. The current behavior has this important
feedback only applying when the user isn't over anything which *can* be clicked
or dragged, which seems to kinda defeat the purpose.
For example, consider someone who clicks on a large image link, and then (as
often happens) moves the mouse a pixel or two immediately following the
mouseup. As soon as the mouse moves the cursor appears as a pointing hand
again, giving the impression that the link isn't loading after all. So the user
is led to click the link again, and again, and again, wondering why it's not
working.
Keywords: pp
Whiteboard: [p-ie/windows]
Comment 3•24 years ago
|
||
Internet Explorer 6.0 for Windows for me does not exhibit the behavior you cite.
I think it was the same for 5.5 also...
Let's not copy bugs in Microsoft products:
http://www.acm.org/archives/wa.cgi?A2=ind0105B&L=chi-web&P=R4099
My original patch in bug 30375 included the desired behavior but the patch
checked in didn't for some reason. Unfortunately I think my original patch is
broken too because of the new way that frames are left until the last minute.
Any idea where in the code the old page is destroyed? I definitely think the
feedback that a new page is going to load soon greatly outweighs the feedback
that you can still click on other links.
The second issue is what happens AFTER the page starts displaying. Right now
it displays the spinning cursor only where the arrow would otherwise be
displayed. That's good, because we want to indicate that you can click on
links. But that's also bad because most pages consist of text areas that use
the i-beam cursor. So it alternates between i-beam and spinning as you move
across the page, making it difficult to tell what the page status is. Perhaps
the best solution to that is to have "i-beam/hourglass" and "hand/hourglass"
custom cursors, but we don't support those yet.
Another idea is to do what IE has always done as far as I know -- not display a
busy cursor AT ALL when the new page starts displaying. On the one hand you
want to give feedback to the user, on the other hand you don't want to give
them the impression that Mozilla is slow by displaying the hourglass when
nothing obvious is happening. For example.. sometimes I notice that Mozilla is
still displaying the hourglass even though the page appears fully loaded. But
because it's struggling to load the last couple pixels of some image, the
hourglass is still there.
Reporter | ||
Comment 5•23 years ago
|
||
> Any idea where in the code the old page is destroyed?
I think Hyatt wrote that bit.
>...
> Another idea is to do what IE has always done as far as I know -- not display
> a busy cursor AT ALL when the new page starts displaying.
MSIE can get away with that because (in versions 5.0 and later, on both Windows
and Mac OS) it doesn't do incremental rendering of tables. So my `yes, you can
still click or drag, but be warned that what's under the cursor might change at
any moment, so your click or drag might not have the desired effect' rule for
using the spinning cursor doesn't apply, because what's under the cursor
*won't* change at any moment.
For Mozilla, perfect behavior would be for us to be able to tell which parts of
the page might be reflowed later during the load, and which parts won't be, and
use the spinning and page-specified cursors respectively. But I imagine that
would be prohibitively difficult to implement, and it's not the focus of this
bug. :-)
Whiteboard: [p-ie/windows] → [p-ie/windows] [p-ie/mac]
Comment 6•23 years ago
|
||
marking p5, future, and helpwanted
Comment 8•23 years ago
|
||
->XP Apps default assignee
Assignee: blaker → trudelle
Component: XP Apps: GUI Features → XP Apps
Comment 9•23 years ago
|
||
sorry, this was supposed to be XPApps: GUI Features
Assignee: trudelle → blaker
Component: XP Apps → XP Apps: GUI Features
Updated•23 years ago
|
Target Milestone: --- → Future
Comment 10•22 years ago
|
||
Taking, changing platform to all.
Assignee: blaker → tim
Keywords: helpwanted
OS: Mac System 9.x → All
Hardware: Macintosh → All
Target Milestone: Future → mozilla1.2beta
Comment 11•22 years ago
|
||
This implements the requested behavior. The event state manager handles the
different busy states (while a link is loading, and when the page is actually
shown). It adds a setter for busyFlags in DocShell, so that the busy state can
be changed from the PresShell when the painting is unsuppressed and the new
document is actually visible.
Attachment #106636 -
Flags: review?(adamlock)
Comment 12•22 years ago
|
||
tim@prismelite.com: is this bug/patch still valid ? if yes : Please ask adamlock
again for the review..
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 13•18 years ago
|
||
worth persuing?
Updated•16 years ago
|
Priority: P5 → --
QA Contact: bugzilla → nobody
Target Milestone: mozilla1.2beta → ---
Comment 14•16 years ago
|
||
Move to Core->Doc Navigation
Assignee: tim → nobody
Component: UI Design → Document Navigation
Product: SeaMonkey → Core
QA Contact: nobody → docshell
Comment 15•16 years ago
|
||
I don't think adamlock is going to ever review this, so this needs a different reviewer. And it needs ui-review first, before we start messing with the code.
Updated•16 years ago
|
Attachment #106636 -
Flags: ui-review?(beltzner)
Comment 16•15 years ago
|
||
Mike, if you're not the right ui-reviewer for this, who might be?
Updated•13 years ago
|
Attachment #106636 -
Attachment is obsolete: true
Attachment #106636 -
Flags: ui-review?(mbeltzner)
Attachment #106636 -
Flags: review?(adamlock)
Comment 17•13 years ago
|
||
we don't have a spinning cursor anymore
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•