Manage bookmark commands broken

VERIFIED FIXED in mozilla0.9.2


Bookmarks & History
17 years ago
14 years ago


(Reporter: doctor__j, Assigned: David Hyatt)


Windows 98

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
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.

Comment 1

17 years ago
All commands are broken.

Workaround: Launch a new window (Ctrl-N).  Then the bookmark manager will wake
up and really respond to your command.

Comment 2

17 years ago
WFM with 2001-06-01-13 (CVS) on Linux.

Comment 3

17 years ago
wfm 2001053121 linux

Comment 4

17 years ago
I'm seeing this on Windows 98 SE with build 2001060104. The workaround that
doctor_j suggested doesn't work for me.

Comment 5

17 years ago
*** Bug 83885 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
I'm seeing this with 2001060120 Win2k. The workaround works for me.

Comment 7

17 years ago
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

Comment 8

17 years ago
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?

Comment 9

17 years ago

Double click on a bookmark (not a folder).  This should wake up the Bookmark 
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. 
Keywords: nsbeta1
Priority: -- → P1
Target Milestone: --- → mozilla0.9.2

Comment 11

17 years ago
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 :(

Comment 12

17 years ago
FWIW the history window has the same problem. I suspect most spawned windows do.
Big strange bug going on here. Adding saari to cc.

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.


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

Comment 14

17 years ago
This should be nsCatFood, nsDogFood, nsenterprise, correctness, dataloss. Very
serious problem.

Comment 15

17 years ago
Fixed by 83707.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 16

17 years ago
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 :-)

Comment 17

17 years ago
Fabian, if you feel like Bugzilla comments are spam, turn off e-mail in your
communcation settings.


17 years ago
Resolution: FIXED → ---

Comment 18

17 years ago
reopening. not fixed.


17 years ago

Comment 19

17 years ago
Created attachment 37097 [details] [diff] [review]
Patch to fix problem.

Comment 20

17 years ago
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.

Comment 21

17 years ago

Comment 22

17 years ago

Comment 23

17 years ago

Comment 24

17 years ago
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 25

17 years ago
*** Bug 83940 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
Works for me 2001060504 Win98

Comment 27

17 years ago
*** Bug 83626 has been marked as a duplicate of this bug. ***

Comment 28

17 years ago
Verified on Win98, marking as such.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.