Bookmarks folders display empty

VERIFIED FIXED in mozilla1.8.1alpha1

Status

()

Core
XUL
--
major
VERIFIED FIXED
12 years ago
10 years ago

People

(Reporter: sgautherie, Assigned: bz)

Tracking

({regression, verified1.8.0.4, verified1.8.1})

1.8 Branch
mozilla1.8.1alpha1
x86
All
regression, verified1.8.0.4, verified1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.0.4 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
[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.

Comment 1

12 years ago
Also broken in OS/2 20060421 1.1a/1.8
OS: Windows 98 → All

Comment 2

12 years ago
Bookmarks were working in 2006042017 1.1a

Updated

12 years ago
Flags: blocking-seamonkey1.1a+
(Reporter)

Comment 3

12 years ago
(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.)
(Reporter)

Comment 4

12 years ago
(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.
(Reporter)

Comment 5

12 years ago
(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.

Comment 6

12 years ago
Also broken in 2006042113 (1.8) on Mac OS 10.3.9
(Reporter)

Comment 7

12 years ago
(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?
(Reporter)

Comment 9

12 years ago
(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....
(Reporter)

Comment 11

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

Comment 12

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

Comment 13

12 years ago
comment 12 is 2006042105
(Reporter)

Comment 14

12 years ago
(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 ?
(Reporter)

Comment 16

12 years ago
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 :-|]

Comment 17

12 years ago
this regressed from bug 329677.
Target Milestone: seamonkey1.1alpha → ---
(Reporter)

Comment 18

12 years ago
(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?
Blocks: 329677
Component: Bookmarks → XP Toolkit/Widgets: XUL
Flags: blocking-seamonkey1.1a+
Product: Mozilla Application Suite → Core
QA Contact: bookmarks → xptoolkit.xul
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?
Flags: blocking1.8.1?
Flags: blocking1.8.0.3?
(Reporter)

Comment 21

12 years ago
(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>
Created attachment 219571 [details] [diff] [review]
Try for both -- this fixes the bug for me
Attachment #219571 - Flags: superreview?(neil)
Attachment #219571 - Flags: review?(enndeakin)
Attachment #219571 - Flags: approval1.8.0.3?
Attachment #219571 - Flags: approval-branch-1.8.1?(neil)

Comment 23

12 years ago
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?
Attachment #219571 - Flags: superreview?(neil)
Attachment #219571 - Flags: superreview+
Attachment #219571 - Flags: approval-branch-1.8.1?(neil)
Attachment #219571 - Flags: approval-branch-1.8.1+

Comment 24

12 years ago
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.
Attachment #219571 - Flags: review?(enndeakin) → review+
(Reporter)

Comment 25

12 years ago
(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.
Assignee: nobody → bzbarsky
Flags: blocking1.8.0.3? → blocking1.8.0.3+
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
Attachment #219571 - Flags: approval1.8.0.3? → approval1.8.0.3+
Fixed on both branches (not needed on trunk).
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8.0.3, fixed1.8.1
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8.1alpha1
(Reporter)

Comment 28

12 years ago
(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" ?
(Reporter)

Comment 29

12 years ago
[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.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1 → verified1.8.1
Yes.  It may or may not be necessary, but it doesn't hurt and I'd rather be safe than sorry.

Updated

12 years ago
Keywords: fixed1.8.0.4 → verified1.8.0.4

Updated

12 years ago
Depends on: 346288

Updated

12 years ago
Flags: blocking1.8.1?

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.