Open Bug 103816 Opened 24 years ago Updated 9 years ago

add UI for "mailnews.nav_crosses_folders"

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

People

(Reporter: Marcin.Kasperski, Unassigned)

References

Details

When I press space after reading the last message from some newsgroup, I get the following dialog box: Advance to next unread message on newsgroup... OK Cancel In my opinion, this dialog should be removed. This is the classical sample of spoiling the user interaction. When I press space, I want to move to the next unread message.
Yes, but do you want to move to the next _newsgroup_? Before this was added people had problems advancing to things when they really did not want to, iirc.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
morphing bug. there's a hidden pref you can set. "mailnews.nav_crosses_folders" 0: "next" goes to the next folder, without prompting 1: "next" goes to the next folder, and prompts (the default) 2: "next" will not go to the next folder. reporter, you want to add this to your prefs.js: user_pref("mailnews.nav_crosses_folders",0); There is no pref UI for this. We could put a checkbox in the "Advance to ..." dialog ([ ] "Don't warn me" or something, to toggle the value from 0 to 1. (2 would still be a hidden value) cc jglick for comments. this UI issue is low priority.
Summary: Please, remove 'Advance to next unread message...' dialog → add UI for "mailnews.nav_crosses_folders"
Severity: minor → enhancement
QA Contact: esther → laurel
If enough people feel this is important, we can add UI to control this. This would be a Global prefs (vs per Account)?
Keywords: nsbeta1
Keywords: nsbeta1nsbeta1-
Target Milestone: --- → mozilla1.0.1
Per-account? Teehee. If the pref was on in account A, and off in account B, and you were on the last unread message in account A, and the next unread message was in account B, and you pressed Space, what would happen? :-) But seriously ... The whole idea of putting up an alert for this is broken, regardless of whether there's an option to turn it off. You should only put up an alert asking a question if the user is in danger, and that's certainly not the case here. Instead, I suggest replacing the contents of the message pane with a placeholder page (like bug 28586), as follows. [i] There are no more unread messages in this folder. To continue to the next folder or group containing unread messages, press the Space key again. That way it's not too easy to go to another folder if you didn't mean it (you have to press Space twice, not once), but it doesn't disturb the flow of repeatedly pressing Space to go through all your newsgroups. Then the pref can be taken out the back and shot.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Blocks: 370090
Assignee: mail → nobody
QA Contact: laurel → message-display
Target Milestone: mozilla1.0.1 → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
Valid enhancement request.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: EXPIRED → ---
Status: REOPENED → NEW
You need to log in before you can comment on or make changes to this bug.