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)

defect
Not set
trivial

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.
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
Keywords: pp
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]
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.
> 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]
Blocks: 98474
marking p5, future, and helpwanted
Keywords: helpwanted
Priority: -- → P5
Target Milestone: --- → Future
->default assignee
Assignee: pchen → blaker
Target Milestone: Future → ---
->XP Apps default assignee
Assignee: blaker → trudelle
Component: XP Apps: GUI Features → XP Apps
sorry, this was supposed to be XPApps: GUI Features
Assignee: trudelle → blaker
Component: XP Apps → XP Apps: GUI Features
Target Milestone: --- → Future
Taking, changing platform to all.
Assignee: blaker → tim
Keywords: helpwanted
OS: Mac System 9.x → All
Hardware: Macintosh → All
Target Milestone: Future → mozilla1.2beta
Attached patch DocShell/PresShell/Event State Manager patch (obsolete) (deleted) — Splinter Review
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)
tim@prismelite.com: is this bug/patch still valid ? if yes : Please ask adamlock again for the review..
Product: Core → Mozilla Application Suite
worth persuing?
Component: XP Apps: GUI Features → UI Design
Priority: P5 → --
QA Contact: bugzilla → nobody
Target Milestone: mozilla1.2beta → ---
Move to Core->Doc Navigation
Assignee: tim → nobody
Component: UI Design → Document Navigation
Product: SeaMonkey → Core
QA Contact: nobody → docshell
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.
Attachment #106636 - Flags: ui-review?(beltzner)
Mike, if you're not the right ui-reviewer for this, who might be?
Attachment #106636 - Attachment is obsolete: true
Attachment #106636 - Flags: ui-review?(mbeltzner)
Attachment #106636 - Flags: review?(adamlock)
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.

Attachment

General

Creator:
Created:
Updated:
Size: