83642 - Manage bookmark commands broken

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P1)

Description

[doctor__j]

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

[doctor__j]

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

[André Dahlqvist]

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

Comment 3

[Gilles Durys]

wfm 2001053121 linux

Comment 4

[Alex]

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

Comment 5

[Ferdinand]

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

Comment 6

[Oliver Klee]

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

Comment 7

[Fabian Guisset]

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.

Comment 8

[Ken Nemunaitis]

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

[Chris Lyon]

Workaround:

Double click on a bookmark (not a folder).  This should wake up the Bookmark 
Manager.

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 11

[Fabian Guisset]

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

[Fabian Guisset]

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

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 14

[Skewer]

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

Comment 15

[David Hyatt]

Fixed by 83707.

Comment 16

[Fabian Guisset]

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

[Skewer]

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

Comment 18

[David Hyatt]

reopening. not fixed.

Comment 19

[David Hyatt]

Attachment: Patch to fix problem.

Comment 20

[David Hyatt]

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

[jag (Peter Annema)]

r=jag

Comment 22

[Blake Ross]

sr=blake

Comment 23

[tor]

a=tor

Comment 24

[David Hyatt]

Fixed.

Comment 25

[David Hyatt]

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

Comment 26

[Skewer]

Works for me 2001060504 Win98

Comment 27

[Jesse Ruderman]

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

Comment 28

[Skewer]

Verified on Win98, marking as such.