Closed Bug 69810 Opened 25 years ago Closed 25 years ago

Manage Bookmarks broken.

Categories

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

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.8.1

People

(Reporter: tarahim, Assigned: bugs)

References

Details

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

Attachments

(2 files)

patch for domSharedPrefix.h
541 bytes, patch
Details | Diff | Splinter Review
patch for domSharedPrefix_debug.h
577 bytes, patch
Details | Diff | Splinter Review
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.
Keywords: mozilla0.9, regression
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.9 → mozilla0.8.1
damn this is annoying.
Keywords: nsdogfood
Yes, bookmarks are hosed in the mac. Marking nsbeta1+, p1, mozilla0.8.1.
Keywords: nsbeta1 → nsbeta1+
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: 25 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: