Closed
Bug 113448
Opened 23 years ago
Closed 14 years ago
Cancel button on bookmark update notification dialog doesn't work as expected
Categories
(SeaMonkey :: Bookmarks & History, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: matzon, Unassigned)
References
Details
(Keywords: useless-UI)
1 - Make a bookmark, and set it to be scheduled and flag 'Display an alert' 2 - When the alert is presented, mark 'Stop checking for updates on this page' 3 - press cancel Alert should no more pop up, yet it does...? Additionally - shouldn't the buttons read Yes/No ?
Comment 2•22 years ago
|
||
Seems to me that the cancel button is unnecessary... <msg> [x] Alert me when... [ OK ] seems like it would suffice. Resummarizing slightly.
Status: NEW → ASSIGNED
Ever confirmed: true
Summary: Bookmarks doesn't handle cancel on 'Display an alert' → Cancel button on bookmark update notification dialog unnecessary
Target Milestone: --- → mozilla1.2
Comment 3•22 years ago
|
||
*** Bug 136090 has been marked as a duplicate of this bug. ***
Comment 4•22 years ago
|
||
*** Bug 158330 has been marked as a duplicate of this bug. ***
Comment 5•22 years ago
|
||
*** Bug 159164 has been marked as a duplicate of this bug. ***
Comment 6•22 years ago
|
||
hummm I dont agree with the previous comment. a cancel (rather ignore) option is mandatory. What I'd like as behaviour would be : 1. change label 'CANCEL' to 'IGNORE' and clicking on it would prevent mozilla to open the bookmark link (see bug #188386) 2. if OK is clicked then open the bookmark link 3. in both cases, record the request (checkbox) to go on checking this bookmark regularly on the specified current time interval. - not checked => go on verifying bookmark updates as usual - checked => skip verifying till the end of the current time interval (ie: if interval is 8am to 8pm and we are 6pm dont verify anymore until past 8am tomorrow) the ignore choice is mandatory in order to avoid unnecessary opening a window when we dont want to at first notification.
Comment 7•21 years ago
|
||
How about +-------------.... | | Foo has changed, | last update at <time> | | [.] Stop checking for updates on Foo | | [ Show me ] [ Ignore ] | +-------------.... That way, there can be no doubt about meanings. The 'Stop checking' is updated regardless what button you pushed.
Comment 8•21 years ago
|
||
I also think this button should stay and be renamed to Ignore or No. Depends on the question 3. So this dialog should in my opinion look something like this: 1. Information about which page/bookamrk has been updated and maybe when was it last checked for updates. 2. A checkbox with a text like "Continue checking this page for updates" 3. A question "Would you like Mozilla to Open this page now?" 4. Buttons Yes and No
OS: Windows 2000 → All
Comment 9•21 years ago
|
||
*** Bug 188386 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Summary: Cancel button on bookmark update notification dialog unnecessary → Cancel button on bookmark update notification dialog doesn't work as expected
Updated•20 years ago
|
Keywords: useless-UI
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 10•19 years ago
|
||
I was just bitten by this bug. I found this bug thread and thought I'd chime in since no one else has for a year and a half. I like the ignore idea. The button is mandatory. Removing it shouldn't even be a consideration. During an update cycle on a watched webpage the webmaster may update it a couple dozen times in a short period of time. Do we really want to be forced to spawn a new window each and every time an update occurs? Personally I'd like to see a timer added to the check-for-updates feature that allows me to ignore updates for the next X time period (minutes, hours, days, etc) without having to tell it to forget about watching the bookmark entirely. Think of it like a snooze button on an alarm clock. That's my $.02. The bug still exists in 1.7.5.
Comment 11•19 years ago
|
||
This has bugged me for years, so I finally looked at the code. The fundamental problem regards the semantics of the bookmark property notification checkbox items "Display an alert" and "Open web page in a new window". By itself the "open" item currently means: Open a web page in a new window *irrespective of any other user action*. By itself the "alert" item currently means: Display an alert with info about the updated page and open a web page in a new window iff the user clicked OK to the prompt. The problem is with the interaction of these two items; I propose to change the "open" item to mean "Open a web page in a new window unless the user was prompted and didn't want it." nsBookmarksService::OnStopRequest() pseudocode: if bookmarked page changed { // update schedule bookkeeping // icon/beep handling openURLFlag = FALSE if "show an alert" requested in bookmark properties issue prompt popup with response in openURLFlag if openURLFlag || "open a new window" requested in bookmark properties open bookmarked page } I suggest the following simple improvement (3 lines in the code): openURLFlag = FALSE alertedFlag = FALSE if "show an alert" requested in bookmark properties { alertedFlag = TRUE issue prompt popup with response in openURLFlag } if openURLFlag || (!alertedFlag && "open a new window" requested in bookmark properties) open bookmarked page (The "Display an alert" and "Open web page in a new window" items are currently "orthogonal", but they probably should be "hierarchical" - sorry, I'm a dinosaur CLI programmer and don't know the right GUI terminology - "alert" should be a sub-option to "open". That way the behavior of the options would be clearer to users, but I'd really like to submit a patch for the above tweak for inclusion in 1.8 and defer any further improvement...)
Updated•16 years ago
|
Assignee: bugs → nobody
Status: ASSIGNED → NEW
QA Contact: claudius → bookmarks
Target Milestone: mozilla1.2alpha → ---
Comment 12•15 years ago
|
||
MASS-CHANGE: 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
Comment 13•14 years ago
|
||
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: 14 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•