[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060419 SeaMonkey/1.1a] (nightly) (W98SE) Works fine. [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060422 SeaMonkey/1.1a] (nightly) (W98SE) Bookmarks UI is broken, in Bookmarks menu or Personnal Toolbar: tooltips do not appear when mouse is hover; and when clicking to open a folder, it opens empty. Yet the Bookmarks file remains fully correct.

Also broken in OS/2 20060421 1.1a/1.8

Bookmarks were working in 2006042017 1.1a

(In reply to comment #0) > [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060422 SeaMonkey/1.1a] > (nightly) (W98SE) [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060423 SeaMonkey/1.1a] (nightly) (W98SE) (Still there) > tooltips do not appear when mouse is hover; Forget the tooltip part: the patch for this feature has not been checked in yet on branch :-< (In reply to comment #2) > Bookmarks were working in 2006042017 1.1a Yes, in 0419 too. I have not reinstalled 0420 to check. (Windows 0421 directory is empty on Ftp site/mirror.)

(In reply to comment #3) > (In reply to comment #2) > > Bookmarks were working in 2006042017 1.1a > > Yes, in 0419 too. > I have not reinstalled 0420 to check. Oh, I misread the 17 ... then the timeframe is between the 20th and the 22th.

(In reply to comment #4) > Oh, I misread the 17 ... then the timeframe is between the 20th and the 22th. Argh... The timeframe is between the 20th and the 21th only, per comment 1 on OS/2.

Also broken in 2006042113 (1.8) on Mac OS 10.3.9

(In reply to comment #1) > Also broken in OS/2 20060421 1.1a/1.8 This one should be </seamonkey/nightly/contrib/2006-04-21-09-mozilla1.8>.

So can someone who can reproduce this do builds by date or whatever to narrow this down?

(In reply to comment #8) > So can someone who can reproduce this do builds by date or whatever to narrow > this down? From the current timeframe (see bug URL), I would guess one of the following bugs: [[ 2006-04-20 20:30 dbaron%dbaron.org mozilla/content/xul/content/src/nsXULElement.h 1.190.4.2 MOZILLA_1_8_BRANCH 3/4 Fix null check so it doesn't cause a leak. b=315427 r+sr+a=bryner 2006-04-20 19:11 bryner%brianryner.com mozilla/content/html/content/src/nsHTMLButtonElement.cpp 1.139.2.4 MOZILLA_1_8_BRANCH 3/1 Fix focus-stealing for button elements (bug 299677). Patch by darin, r=me sr=dveditz b181=me. 2006-04-20 18:40 bzbarsky%mit.edu mozilla/layout/generic/nsSelection.cpp 3.199.2.11 MOZILLA_1_8_BRANCH 27/2 Bug 328395: deal with an nsTypedSelection existing after its presentation is destroyed so it doesn't crash. Patch by Eli Friedman <sharparrow1@yahoo.com>, r=bzbarsky, sr=roc, branch181=roc ]] (But I wouldn't know.)

Yeah, none of those look like they should really cause this....

NB: I can't create/compile builds, I can only test builds from tinderboxen (or if someone could create a (debug) build maybe)...

SeaMonkey 1.1a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060421 SeaMonkey/1.1a is OK.

comment 12 is 2006042105

(In reply to comment #13) > comment 12 is 2006042105 Windows, OS/2, MacOSX: have the bug. Linux: Does a current (0422+) nightly have the bug ?

Linux 2006042300 1.8 has the bug

Then, 4 hours (= 6 checkins) regression timeframe between 2006-04-21-05 Linux (comment 13) and 2006-04-21-09 OS/2 (comment 7) [Even more clueless than before :-|]

this regressed from bug 329677.

(In reply to comment #17) > this regressed from bug 329677. This one is 3 checkins (= 5 hours) after the timeframe, but I won't complain. [[ 2006-04-21 13:45 bzbarsky%mit.edu mozilla/content/xul/document/src/nsXULDocument.cpp 1.664.2.16 MOZILLA_1_8_BRANCH 4/1 Fix bug 329677. Sort service patch by Neil Rashbrook, r=ndeakin, sr=bzbarsky. The rest of the patch by me, r=pike, sr=Neil Rashbrook, branch181=Neil Rashbrook ]] This bug has restricted access. Let's wait for a solution from Boris or Neil.

I will now state with a high degree of confidence that the timeframes in this bug are completely bogus. The checkin that caused this is for bug 329677; confirmed via local backout. Of course I first had to spend most of the day combing the bogus regression range given in this bug. :( Neil, Neil, Axel, any idea what's up here? Is the XUL sort service fix we put in not enough?

So on the 1.8 branch, there's a remaining caller of GetElementResource. Specifically, nsXULContentUtils::GetElementRefResource calls it and is called from various places in the template builder. Simply replacing that GetElementResource call by QI to nsIDOMXULElement and GetResource() works. But are we guaranteed that we have a XUL element there? Or should this code be doing something more like what XULSortServiceImpl::InsertContainerNode does after the patch for bug 329677? Or both?

(In reply to comment #19) > I will now state with a high degree of confidence that the timeframes in this > bug are completely bogus. The checkin that caused this is for bug 329677; > confirmed via local backout. Of course I first had to spend most of the day > combing the bogus regression range given in this bug. :( I'm sorry about that, really ! I tried to make a guess in comment 7... If we set aside comment 1: the narrowest timeframe becomes between 21-05 and 21-13(+1h), which includes the culprit bug. <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-21+05&maxdate=2006-04-21+13:59&cvsroot=%2Fcvsroot>

Comment on attachment 219571 [details] [diff] [review] Try for both -- this fixes the bug for me It looks to me as if a) the else portion is no longer necessary b) the original patch didn't land on the 1.8.0.x branch?

Comment on attachment 219571 [details] [diff] [review] Try for both -- this fixes the bug for me Looks OK, although the else clause isn't necessary.

(In reply to comment #23) > (From update of attachment 219571 [details] [diff] [review] [edit]) > It looks to me as if [...] b) the original > patch didn't land on the 1.8.0.x branch? Per LXR, it has not (as yet): Trunk and 1.8.1 only.

Comment on attachment 219571 [details] [diff] [review] Try for both -- this fixes the bug for me approved for 1.8.0 branch, a=dveditz for drivers

Fixed on both branches (not needed on trunk).

(For the record, Boris has now checked in bug 329677 fix on 1.8.0 branch.) Boris, is it intentional that you landed the full patch, while the reviewers seemed to think that "the else clause isn't necessary" ?

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060424 SeaMonkey/1.1a] (tinderbox-builds, 2006042413) (W98SE) V.Fixed on 1.8.1 branch.

Yes. It may or may not be necessary, but it doesn't hurt and I'd rather be safe than sorry.