Closed Bug 69810 Opened 23 years ago Closed 23 years ago

Manage Bookmarks broken.

Categories

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

PowerPC
Mac System 9.x
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.8.1

People

(Reporter: tarahim, Assigned: bugs)

References

Details

(Keywords: helpwanted, regression, Whiteboard: critical for 0.8.1)

Attachments

(2 files)

2001022204 Mac trunk build.
Manage Bookmark window is broken.
Select All, Delete, Cut, Paste are unavailable.
Can not edit a bookmark item-what was the menu item for this?-Command+i is not
working, at the least.
New Bookmark, New Folder, New Separator do not work.
I see this as well (02/22/01-08 trunk). Looks like it's not recognizing the
bookmarks (all the menu commands/toolbar items are there, but when you select a
bookmark, they don't become active). Also, I am unable to add a new bookmark
from the browser window. Most of these worked in the 02/20 build (I think new
separator has been broken for awhile).
My question is, how is this not a blocker? In today's builds, you can't do squat
with bookmarks. I think there's at least one bookmarks exercise in the smoketests.
Right, and it involves opening a new window from bookmarks only.
That works in this build.
nominating for nsbeta1. this seems to be a very recent regression as I don't see this
problems in the 2001022108 build
Keywords: nsbeta1
Smoketest B.22:
1. Use Bookmarks | Add Current Page to add a bookmark. 
2. Select Bookmarks | Manage Bookmarks. 
3. Locate new bookmark and double-click. This should launch a new, chromed 
browser window.

So, unless people are cheating, it should have failed (couldn't add a new 
bookmark in 02/22 build).
I know what you mean Akay, but occasionally you can add bookmarks even in 0222
build.(I do not know the exact condition yet) Therefore, it is possible that it
actually passed the smoketest at that time.
Is this a duplicate of the meta Manage Bookmarks bug (bug 68550), or should it
have a more specific summary, or does Manage Bookmarks not work under Mac at all?
This is not a meta bug. It started in this specific build, and therefore it
should be considered a single bug. And yes, it is totally broken.
Blocks: 68550
*** Bug 70260 has been marked as a duplicate of this bug. ***
Snagging keywords from bug 70260 and putting them up here.
Nominating for mozilla0.8.1 - I doubt a milestone will ship without functional
bookmarks. You can currently add bookmarks, and rearrange them, but nothing else.
Keywords: mozilla0.9mozilla0.8.1
damn this is annoying. 
Keywords: nsdogfood
Yes, bookmarks are hosed in the mac. Marking nsbeta1+, p1, mozilla0.8.1.
Keywords: nsbeta1nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla0.8.1
Whiteboard: critical for 0.8.1
This is a bad problem but unfortunately NZ Customs is fucking me over and I 
don't have a mac so I can't look at this. This bug should block .8.1, IMO. Help! 
Flail!

If someone with a mac wants to sit down with me and debug this (where 'sit down' 
means converse over AIM or telephone), let me know. 
Severity: critical → blocker
Keywords: helpwanted
*** Bug 71302 has been marked as a duplicate of this bug. ***
*** Bug 71490 has been marked as a duplicate of this bug. ***
I can converse with you ben!
looking at bonsai, adding two people who have checked mac things that *could*
have affected bookmarks. Sorry if you have nothing to do with this.
hyatt@netscape.com for the fix for bug 69142
dougt@netscape.com : mac bookmarks broke right after you landed your necko
changes the 21st of february
pchen debugged this a little last week and found that 
nsXULControllers::GetControllerForCommand was failing to find a controller for 
any of the affected commands. This implies that there is no controller in the 
mControllers array on nsXULControllers that supports the given command (as 
SupportsCommand is called on each controller in the array). 

This is interesting, as the controller that handles these operations is added in 
the bookmarks window's load handler (using 
document.controllers.AppendController(jsobj)). Either that is failing, or 
somehow the controller is getting removed by someone along the line...
Status: NEW → ASSIGNED
dougt/hyatt, and thoughts on this bug?
this is not dougt.
That is the nicest thing you have ever said to me pink. :-)
Found the problem. There are two #ifdef INCLUDE_XUL's in 
mozilla/dom/src/base/nsFocusController.cpp. The one we're interested in is on 
line 144:

#ifdef INCLUDE_XUL
    nsCOMPtr<nsIDOMXULElement> xulElement(do_QueryInterface(mCurrentElement));
    if (xulElement)
      return xulElement->GetControllers(aResult);
#endif

diffs forthcoming
Hmm, I forgot to mention that INCLUDE_XUL isn't defined for mac dom project. So 
the fix is to, duh, turn in on! So this explains why we only see this on mac.
got an r=mcafee and sr=hyatt, we're all wondering how we didn't notice this 
earlier
a=asa for checkin to 0.8.1
Fix checked into trunk. According to leaf and granrose, 0.8.1 branch hasn't been 
cut yet (whew).
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
why wasn't this just put in MozillaDefines.h since it's a global define? It's 
defined globally on win32/linux, which is why we're in this predicament in the 
first place.

I disagree with the placement of the #define, but not enough to reopen the bug. 
I'll just give pchen a wedgie on monday ;)
*** Bug 72356 has been marked as a duplicate of this bug. ***
I agree with pinkerton. In fact, I'd suggest that INCLUDE_XUL should key off 
options xul in the build scripts, which defaults to 1.
verified fixed with mac commercial build 2001-03-19-12-trunk
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: