From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9+) Gecko/20010531 BuildID: 2001053120 I cannot delete, create, rename and view properties of bookmarks and bookmark folders in bookmark manager. What's going on here?? Reproducible: Always Steps to Reproduce: 1. Open bookmark manager. 2. Select a bookmark / bookmark folder 3. Press "Properties", "Rename" & "Delete" button on toolbar or equivalent use keyboard shortcuts or menu commands. Actual Results: No response to command issued.
All commands are broken. Workaround: Launch a new window (Ctrl-N). Then the bookmark manager will wake up and really respond to your command.
WFM with 2001-06-01-13 (CVS) on Linux.
wfm 2001053121 linux
I'm seeing this on Windows 98 SE with build 2001060104. The workaround that doctor_j suggested doesn't work for me.
*** Bug 83885 has been marked as a duplicate of this bug. ***
I'm seeing this with 2001060120 Win2k. The workaround works for me.
Marking critical. Can anyone figure out if this also affects 0.9.1? Anyone on Windows (since this seems windows-only) could back out the patch for bug 74499 (two lines in navigator.js) to see if it fixes the problem? It's the only checkin I could find that sounds relevant, apart from the style branch landing that shouldn't have affected this.
Severity: major → critical
Fabian Guisset, this bug does not affect 0.9.1. Try the lastest build under Windows 98 and was able to manage bookmarks normally. Target Milestone 0.9.2?
Workaround: Double click on a bookmark (not a folder). This should wake up the Bookmark Manager.
None of the commands seem to work when the window focuses the first time. Workaround: blur, then refocus window. Looking into it, but I doubt that this is actually my bug.
Priority: -- → P1
Target Milestone: --- → mozilla0.9.2
I removed the window.focus() that was added in bug 74499 and it doesn't seem to fix the problem. I don't know what else could have caused this :(
FWIW the history window has the same problem. I suspect most spawned windows do. Big strange bug going on here. Adding saari to cc.
hah. OK, this occurred around the time of hyatt's style landing. Builds prior to the landing do not show the problem (05/31/2001 09:00), but builds from later that day show the problem (05/31/2001 22:00). No other checkins on that day to layout/ or content/, so suspecting this is hyatt. Dave, Testing shows that when the Bookmarks window is displayed, the first item in the tree widget is selected, which causes all commands to be updated (thus all commands are available for the first item in the list). However, when the selection changes, the code that updates commands on selection changes does not fire as the controller for each command is null. Blurring and refocusing the window appears to correct this problem.
Assignee: ben → hyatt
This should be nsCatFood, nsDogFood, nsenterprise, correctness, dataloss. Very serious problem.
Fixed by 83707.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Skewer, I would really appreciate if you would refrain from posting such spam in the future. I think a TM of 0.9.2 and P1 and assigned is enough to figure out this is important. Besides: 1) if this is a correctness issue, then we could mark all the bugs in bugzilla as correctness. 2) there is no "dataloss" involved. Next time you lose your bookmarks because you are not able to do anything with them, send me a postcard. 3) nsCatFood and nsDogFood are imho redundant, although you could argue it's not stated anywhere. 4) what's this hype with nsenterprise. you don't mark "serious" bugs with nsenterprise keywords. 5) CC yourself on bugs you spam, so you can share our pain. Oh last thing, you can always actually help fixing the bug :-)
Fabian, if you feel like Bugzilla comments are spam, turn off e-mail in your communcation settings.
reopening. not fixed.
Because the link traversal check happens AFTER the onload handler (potentially) now, the SetFocusedElement call becomes harmful, since you clear out anything that was focused during the onload. Moreover, the focused element clearout is already being done in nsDocSHell.cpp (it was added by alock), so the call is truly unnecessary here now anyway, regardless of where CheckForFocus ends up. :) Ready for r/sr/a.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago → 17 years ago
Resolution: --- → FIXED
*** Bug 83940 has been marked as a duplicate of this bug. ***
Works for me 2001060504 Win98
*** Bug 83626 has been marked as a duplicate of this bug. ***
Verified on Win98, marking as such.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.