Closed Bug 727414 Opened 12 years ago Closed 11 years ago

Busy cursor in thread and folderpane while reading news (ui.use_activity_cursor = true)

Categories

(MailNews Core :: Networking: NNTP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 24.0

People

(Reporter: stefan.blumenrath, Assigned: h.figge)

References

Details

(Keywords: regression, relnote, Whiteboard: [relnote: sm-only])

Attachments

(1 file, 1 obsolete file)

When reading news, I often get a busy cursor in the folder- and threadpane but not in the messagepane when I switch from one newsgroup to another. It seems to happen, when I switch fast from one posting to another, maybe it complains to any message getting downloaded.
This busy cursor won't leave, until I close mailnews.

Errorconsole says: Zeitstempel: 15.02.2012 14:17:04
Warnung: Das totalSize-Attribut von Fortschrittsereignissen in XMLHttpRequest sollte nicht mehr verwendet werden.
Quelldatei: chrome://messenger/content/messenger.xul
Zeile: 0
Sounds like an extension is causing the message. Try restarting SeaMonkey in Safe Mode: Help->Restart with Addons Disabled.
OK, you're right with the message, but the problem itself is still existing.
My fastest way to reproduce is a group with many unread postings, then keeping 'n' pressed.
Can confirm this for x86 and WinXP on 2.8beta and Trunk.

You have to press 'n' key to advance to the next message *faster* than SM marks the current message as read and clears the busy cursor back to normal. For a fast computer/connection at least a triple-hit of the 'n' key might be necessary to trigger this behaviour, but if you keep hammering on 'n' it's reproducible.

Addiotionaly it seems impossible to trigger this behaviour on SM2.7, therefore marking as regression. (don't have a smaller regression-window, sry)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Windows 7 → All
Hardware: x86_64 → All
Version: SeaMonkey 2.8 Branch → Trunk
Here, the problem still exists with SM 2.8b3.

With me, it always happens when switching to newsgroup B after having read one or more postings in newsgroup A. It doesn't happen after just lurking without reading. It has nothing to do with fast switching between newsgroups or fast repeating to press 'n' key.
@Philip Chee: disabling extensions fixed not the Problem

WinXP-x86 2.8b3
(In reply to Mike Ritter from comment #5)
> @Philip Chee: disabling extensions fixed not the Problem
> 
> WinXP-x86 2.8b3

Sorry, not read correctly. 
Meant disabling extensions not fixed the cursor-problem.
I still see the problem at SM2.8b4 - Maybe it should be listed in 'Known Issues'...
> Maybe it should be listed in 'Known Issues'
OK, CC our website expert.
(In reply to Philip Chee from comment #8)
> > Maybe it should be listed in 'Known Issues'
> OK, CC our website expert.

Hmm, I don't feel this is serious enough. It doesn't seem anything stops working through this. Actually I'm trying to /reduce/ the amount of things we list under Known Issues. Sure, the easiest way would be to fix this issue, but until that happens, what's the impact of this issue on users other than being an annoying?

That said, maybe I'm seeing this, too. I cannot tell for sure, though, since I have tons of add-ons running. I think I could in the past temporarily fix it by compacting all folders.
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #9)
> (In reply to Philip Chee from comment #8)
> > > Maybe it should be listed in 'Known Issues'
> > OK, CC our website expert.
> 
> Hmm, I don't feel this is serious enough. It doesn't seem anything stops
> working through this.

From this point of view you're right.

> Actually I'm trying to /reduce/ the amount of things
> we list under Known Issues. Sure, the easiest way would be to fix this
> issue, but until that happens, what's the impact of this issue on users
> other than being an annoying?

I think, someone being annoyed by this bug makes it worth to appear under known issues. YMMV and just my 2cent.

> That said, maybe I'm seeing this, too. I cannot tell for sure, though, since
> I have tons of add-ons running. I think I could in the past temporarily fix
> it by compacting all folders.

compact folder doesn't stop "my" busy-cursor... I've seen this by now under:
W764 and XP with and without addons
Xubuntu with a clean profile, only subscribed to de.test
I wonder what's meant with "in the past", this is a regression which has not existed in the releases until and including 2.7.x it seems. This behaviour was introduced in SM2.8 (which would mean it should be fixed before relaeasing 2.8, but I guess that's "out of sight"...)
(In reply to commander_keen from comment #11)
> I wonder what's meant with "in the past"

I was looking back from the point in time when I wrote the comment, because I had no busy cursor at that moment. I was not referring to SM versions. Sorry for the confusion.
SM 2.8b5: Problem still exists :-(
(In reply to Reinhard Zwirner from comment #13)
> SM 2.8b5: Problem still exists :-(

Well I guess 2.8b6 will be tagged soon and released tomorrow, and might be the last 2.8 beta, so the bug will probably be in 2.8 final.

Did anyone check whether TB is affected, too? If the bug really is in core MailNews code, searching for and possibly helping to improve a corresponding TB or MailNews Core bug might speed things up since SM devs are unlikely to fix core MailNews bugs.
OK, just checked out TB11b4 - it's not affected. So I think it isn't a core bug?
SM 2.8b6 Still the same ...
Still SM 2.8b6 - but that annoying permanent busy cursor is gone :-). Let's hope it will stay away (fingers crossed).

Maybe it has something to do with the latest Microsoft patchday (yesterday).
Hmm - it's back again :-(. Unfortunately, I can't say when exactly it came back.
I have also noticed that using SM 2.8 and doing a Ctrl+Shift+C on a newsgroup to mark all read will cause the cursor to begin being active.
My last good was 20111116030726
My first bad was 20111127003001

Wide window, but better than nothing, I think.
(In reply to Ruediger Lahl from comment #20)

> Wide window, but better than nothing, I think.

'hafi' from MID 4F634D27.908@hfigge.myfqdn.de has an smaller window:
Last good 20111120224000
first bad 20111121222700
both builds self-compiled
(In reply to Ruediger Lahl from comment #21)
> Last good 20111120224000
> first bad 20111121222700

According to hg pushlog (assuming I used it correctly), there's just a single changeset in that time frame:

http://hg.mozilla.org/comm-central/rev/e57a9c880238
"Bug 226890 - Thunderbird doesn't handle news URIs properly, part 10: Make command-line news handling work."

Joshua, since you're the author of that code, do you have an idea what's going on, and maybe also why TB is not affected (assuming comment 15 is right)?
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #22)
> going on, and maybe also why TB is not affected (assuming comment 15 is
> right)?

No, that isn't correct. I can confirm that TB Trunk is also effected.

My regression window for TB is:
Last good: 20111118144020
First bad: 20111125152540
(In reply to Alfred Peters from comment #24)
> (In reply to Jens Hatlak (:InvisibleSmiley) from comment #22)
> > going on, and maybe also why TB is not affected (assuming comment 15 is
> > right)?
> 
> No, that isn't correct. I can confirm that TB Trunk is also effected.

OK then, if at least one other TB user confirms this, I'll move this bug to MailNews Core (unless someone like Joshua does it before I do of course). I'll also relnote this now (for SM 2.8 and later, until fixed).
Keywords: relnote
Definately a distraction as I use newsgroups extensively:
Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120312 Firefox/11.0 SeaMonkey/2.8
 Multiple confirmations (me too's) on the SeaMonkey support newsgroup.
Downloading the update for Thunderbird & will check to see if I get the same on TB 11.
Any chance of a possible workaround for this?
I've not been able to reproduce (yet) on:
Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120312 Thunderbird/11.0
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #22)

> http://hg.mozilla.org/comm-central/rev/e57a9c880238

It would be nice to be able to back that one out, but unhappily

hafi@i5_64 ~/hg-moz/src $ patch --dry-run -p1 -R < ~/hg-moz/p1
patching file mail/components/nsMailDefaultHandler.js
patching file mailnews/base/util/nsMsgProtocol.cpp
patching file mailnews/news/src/nsNntpIncomingServer.cpp
Hunk #1 succeeded at 767 (offset -2 lines).
patching file mailnews/news/src/nsNntpService.cpp
Hunk #2 FAILED at 1045.
Hunk #3 FAILED at 1711.
(In reply to Alfred Peters from comment #24)

> No, that isn't correct. I can confirm that TB Trunk is also effected.

Ok, in a new profile I also have no bug.

So I checked my config and found that the pref ui.use_activity_cursor was set to true. When I reset it to the TB default value (false), the bug is gone.
(In reply to Alfred Peters from comment #29)
> (In reply to Alfred Peters from comment #24)
> 
> > No, that isn't correct. I can confirm that TB Trunk is also effected.
> 
> Ok, in a new profile I also have no bug.
> 
> So I checked my config and found that the pref ui.use_activity_cursor was
> set to true. When I reset it to the TB default value (false), the bug is
> gone.

Can you (and anyone else using TB and reading this) please re-check how a fresh TB profile behaves with ui.use_activity_cursor = true? Thanks. If you can provide clear steps to reproduce, even better!
Summary: Get busy cursor in thread and folderpane while reading news → Busy cursor in thread and folderpane while reading news (ui.use_activity_cursor = true)
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #30)

> Can you (and anyone else using TB and reading this) please re-check how a
> fresh TB profile behaves with ui.use_activity_cursor = true? Thanks.

Yes, I have the bug in a new profile with that pref set.

>  If you
> can provide clear steps to reproduce, even better!

Steps to reproduce with TB:

1. Subscribe to at last 2 newsgroups (download article)
2. Configure ui.use_activity_cursor = true
3. Select "Group A"
4. Select an article in the Threadpane
5. Select a different group "Group B"

Messagepane is now empty and the busy-cursor occurs when the mouse-cursor is over the folder- or threadpane.
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #30)

> Can you (and anyone else using TB and reading this) please re-check how a
> fresh TB profile behaves with ui.use_activity_cursor = true? Thanks. If you
> can provide clear steps to reproduce, even better!

done. I see the busy-cursor on TB11beta, W7/64
New profile, only newsgroup-account,
1. subscribe de.test
2. change ui.use_activity_cursor to true
3. select any message
4. press and hold 'n' for a few seconds
5. done.
In SeaMonkey 'ui.use_activity_cursor' is per default set on 'true' and in Thunderbird and Firefox per default on 'false'.
Component: MailNews: Message Display → Networking: NNTP
Product: SeaMonkey → MailNews Core
QA Contact: message-display → networking.nntp
Thank you, ui.use_activity_cursor = false seems to solve the problem.
Re: ui.use_activity_cursor
Setting to false in SeaMonkey 2.8 seems to have solved the problem for me. Thanks.

Also tested with Thunderbird 11.0: 
Set 'ui.use_activity_cursor' to true, opened a second newsgroup in a new tab[1] & sure enough the wait cursor appears. Set 'ui.use_activity_cursor' back to false & the problem goes away.

[1] I've found the easiest way to trigger the issue when opening SeaMonkey/Thunderbird is to open a second newsgroup in a new tab. The wait cursor will appear every time (with 'us.use_activity_cursor' set to true).
This appears to be fallout from http://hg.mozilla.org/comm-central/rev/29fd2b00d1ad
c.f. Bug 537015 - Restore the spinner that was removed in bug 481359
CC Neil

Also see:
Bug 482985 - Loading/busy/spinning mouse indicator/pointer/icon missing
Bug 659573 - When enabled ui.use_activity_cursor - don't show busy indicator over toolbars and menu, only when mouse is over page content.
Blocks: 537015
(In reply to Philip Chee from comment #36)
> This appears to be fallout from
If this is fallout (i.e. it wasn't broken before bug 481359) I think it's more likely to be fallout from Thunderbird developers not correctly resetting something and not noticing a problem because their UI doesn't care.
I did the same tests as my comment #35 with SeaMonkey 2.9 and Thunderbird 12: the results are the same. The problem most likely isn't noticed in Thunderbird due ui.use_activity_cursor;false being set as default (see comment #33). You have to manually change it to 'true' in order to reproduce. 

SeaMonkey ui.use_activity_cursor is set to 'true' by default. Is there any reason why this is different than the default for Firefox and Thunderbird?
(In reply to NoOp from comment #38)
> SeaMonkey ui.use_activity_cursor is set to 'true' by default. Is there any
> reason why this is different than the default for Firefox and Thunderbird?

The reasoning of FF's UX guys is explained in bug 482985 comment 113. That comment/decision was the reason why the default of this pref is false for all Gecko-based applications that do not override it. TB doesn't override the pref, but we do (since bug 537015, on all platforms but Mac).
Got it - thanks Jens.
Removing relnote keyword from bugs that are no longer significant or not needing to be mentioned in the release notes.
Keywords: relnote
(In reply to Mark Banner (:standard8) from comment #41)
> Removing relnote keyword from bugs that are no longer significant or not
> needing to be mentioned in the release notes.

I take it that "relnote" on MailNews Core bugs strictly refers to TB then (since this bug still *is* an issue for SM). I guess I'll eventually have to define a SM-specific whiteboard relnote tag...
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #42)
> (In reply to Mark Banner (:standard8) from comment #41)
> > Removing relnote keyword from bugs that are no longer significant or not
> > needing to be mentioned in the release notes.
> 
> I take it that "relnote" on MailNews Core bugs strictly refers to TB then
> (since this bug still *is* an issue for SM). I guess I'll eventually have to
> define a SM-specific whiteboard relnote tag...

Ok, lets go for relnote with an additional whiteboard note.
Keywords: relnote
Whiteboard: [relnote: sm-only]
Attached file BUG (obsolete) —
It seems that this change of cursor from pointer to hourglass has gotten worse in the SM 2.11 release.  I didn't notice it too often previously, but it occurs most of the time now.  Configuration:

User Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11

Extensions (enabled: 7)
* DownloadHelper 4.9.9 (http://www.downloadhelper.net)
* Enigmail 1.4.3 (http://enigmail.mozdev.org/)
* FireFTP 2.0.4 (http://fireftp.mozdev.org)
* Flash and Video Download 1.13 (www.fnvfox.com)
* JavaScript Debugger 0.9.89 (http://www.hacksrus.com/~ginda/venkman/)
* PrefBar 6.1.0 (http://prefbar.tuxfamily.org/)
* Quote Colors 0.3 (http://quotecolors.mozdev.org/)
Attachment #636950 - Attachment is obsolete: true
Attachment #636950 - Attachment is patch: false
Still present in SeaMonkey 2.12. Something I don't see in the above comments that is the easiest way I've found to circumvent it: hit the "Stop" button on the toolbar.
Dick Hoffman
try1 backs out part of the in Comment 22 mentioned suspicious changeset.
Attachment #695294 - Flags: review?(Pidgeot18)
FWIW, for three weeks now i have applied the patch try1 to my daily builds and have not seen the bug since.
I am still applying try1 to my daily builds and do not see the bug. Since it was introduced by a checkin of Joshua, try1 should be reviewed by him.

Well, no response or other comments. I am feeling that i have done what can be expected from a user, so the further progress is up to others.
(In reply to Hartmut Figge from comment #47)
> Created attachment 695294 [details] [diff] [review]
> fix try1

Yes, this fixes the problem also on TB (with 'ui.use_activity_cursor = true').
Attachment #695294 - Flags: review?(Pidgeot18) → review+
After the r+, could someone please take over? try1 is not a proper hg patch and i am not familiar with the required next steps.
Comment on attachment 695294 [details] [diff] [review]
fix try1 [Checkin: Comment 52]

https://hg.mozilla.org/comm-central/rev/89ca38497a74
Attachment #695294 - Attachment description: fix try1 → fix try1 [Checkin: Comment 52]
Assignee: nobody → h.figge
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 24.0
You need to log in before you can comment on or make changes to this bug.