Closed Bug 537507 Opened 15 years ago Closed 15 years ago

Bookmarks and History Sidebars Empty on Initial Opening

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: fred.flange, Assigned: bzbarsky)

References

Details

(Keywords: regression)

Attachments

(1 file)

Fix + tests.
4.49 KB, patch
jst
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100101 Minefield/3.7a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100101 Minefield/3.7a1pre (.NET CLR 3.5.30729)

When I open Bookmarks or History SideBars initially they are empty.

If I switch from one to the other, then the second one displays as normal, and switching back to the original one also shows a normal display.

This happens either way around i.e. Open History [Blank] - Open Bookmarks [O.K.]  -OR- Open Bookmarks [Blank] - Open History [O.K.]

On subsiquent switching between the two all is normal, but if the SideBar is closed and then re-opened during the same session, the same problems present themselves.

First noticed this today 02JAN10 - so assume result of latest 'overnight'

Can provide details of AddOns etc. if this will help.

Reproducible: Always

Steps to Reproduce:
1. Open SideBar - Blank
2. Switch SideBar - OK
3. Subsiquent Switch OK until SideBar Closed.
Actual Results:  
As above

Expected Results:  
Open SideBar with info on first call.

n/a
Confirming under Linux as well.
Issue also occurs if you open bookmarks sidebar using ctrl+b (bookmarks display) then ctrl+b again to close and then re-open with ctrl+b (sidebar is blank).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Hg bisect revealed:

The first bad revision is:
changeset:   36774:2e580c431f4e
user:        Boris Zbarsky <bzbarsky@mit.edu>
date:        Thu Dec 31 14:07:57 2009 -0500
summary:     Bug 528306 part 3.  Hook up restyle processing to nsRefreshDriver.  r=dbaron
Blocks: 528306
Version: unspecified → Trunk
For me everything is fine on the initial opening of Minefield, i.e. sidebar bookmarks are present.  After closing the sidebar then subsequent clicks on the bookmark icon yield a totally blank white sidebar.  This is even true in safemode.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100102 Firefox/3.5.6 ID:20100102055840
My own experience matches those of Larry and Fred.

Also occurs in a fresh profile.
Removed keywords regression, regressionwindow-wanted.  I already identified the regressor in comment #2.  Please read the comments in the bug before editing.
Keywords: regression, regressionwindow-wanted
Oops sorry added regression back should have added that when I identified the regressor.  Guess it's my fault.
Keywords: regression
Unfortunately, I am unable to reproduce this issue in a debug enabled build.  Evidently there is some kind of timing issue involved in this.
Steps to reproduce.

1.start firefox with a fresh profile.
2. open bookmarks or history sidebar
3. close bookmarks or history sidebar.
4. open either again.

Sidebar will be empty, it won't even display the lightblue background colour or search box

Switch to history or bookmarks sidebar from bookmarks / history and the sidebar will display the list correctly, including background color.

Regression range is dated back to about the 29th i didn't use the builds from the 30th or 31st so i can't say if it occured in those but i know it was still fine on the 29th.
I should mention... this isn't the only issue im having with bookmark items.
I cannot cut, paste or delete items either ever since the 29th.
(In reply to comment #8)
> Regression range is dated back to about the 29th i didn't use the builds from
> the 30th or 31st so i can't say if it occured in those but i know it was still
> fine on the 29th.

I do not understand this comment.  First you say that the regression dates back tot he 29th, but then you say that the 29th build worked fine.  Which is it?

What is the earliest dated build that has the issue?
Regression window:

Works fine:
http://hg.mozilla.org/mozilla-central/rev/89cf6d3f66f1
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091231 Minefield/3.7a1pre ID:20091231121343

Broken:
http://hg.mozilla.org/mozilla-central/rev/599d0aa600c9
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091231 Minefield/3.7a1pre ID:20091231132117

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=89cf6d3f66f1&tochange=599d0aa600c9
After a click in the empty sidebar it can't be closed anymore with ctrl+h or ctrl+b.
I can reproduce and looking into it, but so far no luck figuring out what's going on.  No untoward JS exceptions (checked via breakpoints in JS_SetPendingException, so it's not like someone is catching them) and the frametree seems to be correct inside the sidebar...
If you click to open / close the bookmarks bar slowly, it doesn't change anything,

however if you click it rapidly, every few times the sidebar is populated.
OK, the last part of comment 14 was a lie, which is where the problem is.  Due to a bug in the fix for bug 404470, removing display:none from an iframe containing a XUL document has been broken.  The change from bug 528306 is that now the style change sometimes happens after onload fires.

The good news is that it's a really simple fix.  Fix and testcases that reproduce the bug 100% reliably coming up.
Blocks: 404470
Attached patch Fix + tests. — — Splinter Review 
This just makes the nsXULDocument::StartLayout code look more like nsContentSink::StartLayout.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #420260 - Flags: review?(jst)
Hello All

Don't know much about this Bug System - reported bug 02JAN10.

Regret will have to leave Beta now as can't use application while this bug exists.

Will I be advised when it has been resolved, any idea how long this will take.

Best regards

Fred F.
Yes, I'm with you Fred.  I can't keep testing Minefield until this is fixed.  I hope it's soon.
Fred, the fix is waiting for review.  How long that will take depends on Johnny's workload; if he hasn't reviewed it in the next week or so I'll probably send him e-mail.

When the bug is fixed, I'll comment here and change is status to RESOLVED and resolution to FIXED.  You'll get e-mail about that, unless you changed your bugzilla preferences to ignore such mails.
Thanx Boris - Sorry to take up the Airwaves, but I wasn't sure how this thing worked. Will keep an eye on the InBox. - Best Fred F.
Attachment #420260 - Flags: review?(jst) → review+
Pushed http://hg.mozilla.org/mozilla-central/rev/a4c65dcecdf6
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Thank you so much Boris.  Works great now.
Hey, I broke it; least I can do is fix it... ;)
Hello All

I raised the original bug.

I am currently on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100113 Minefield/3.7a1pre (.NET CLR 3.5.30729)

And no further appear to be available at this time.

BUT the bug is still there.

Am I missing something?

Best

Fred F.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #27)
 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100113
> Minefield/3.7a1pre (.NET CLR 3.5.30729)

You need to wait till the next nightly is available (patch was checked in after the build you are using was made, that build was made on 20100113).
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Fred, the string after "Gecko" is the date the build was made.  The one you cite in comment 27 is from January 13, 2010.  Builds are made in the morning Pacific time, around 3am; I checked in the patch around 8am pacific on the 13th, so 5 hours after the build you were using was created.
Sorry Boris - just my ignorance - Thanks for your reply

Best

Fred F.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: