Closed
Bug 537507
Opened 15 years ago
Closed 15 years ago
Bookmarks and History Sidebars Empty on Initial Opening
Categories
(Firefox :: Bookmarks & History, defect)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
FIXED
People
(Reporter: fred.flange, Assigned: bzbarsky)
References
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
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
Comment 1•15 years ago
|
||
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
Comment 2•15 years ago
|
||
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
Updated•15 years ago
|
Version: unspecified → Trunk
Comment 3•15 years ago
|
||
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
Comment 4•15 years ago
|
||
My own experience matches those of Larry and Fred.
Also occurs in a fresh profile.
Updated•15 years ago
|
Keywords: regression,
regressionwindow-wanted
Comment 5•15 years ago
|
||
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
Comment 6•15 years ago
|
||
Oops sorry added regression back should have added that when I identified the regressor. Guess it's my fault.
Keywords: regression
Comment 7•15 years ago
|
||
Unfortunately, I am unable to reproduce this issue in a debug enabled build. Evidently there is some kind of timing issue involved in this.
Comment 8•15 years ago
|
||
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.
Comment 9•15 years ago
|
||
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.
Comment 10•15 years ago
|
||
(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?
Comment 11•15 years ago
|
||
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
Comment 13•15 years ago
|
||
After a click in the empty sidebar it can't be closed anymore with ctrl+h or ctrl+b.
Assignee | ||
Comment 14•15 years ago
|
||
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...
Comment 15•15 years ago
|
||
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.
Assignee | ||
Comment 16•15 years ago
|
||
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
Assignee | ||
Comment 17•15 years ago
|
||
This just makes the nsXULDocument::StartLayout code look more like nsContentSink::StartLayout.
Reporter | ||
Comment 19•15 years ago
|
||
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.
Comment 20•15 years ago
|
||
Yes, I'm with you Fred. I can't keep testing Minefield until this is fixed. I hope it's soon.
Assignee | ||
Comment 21•15 years ago
|
||
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.
Reporter | ||
Comment 22•15 years ago
|
||
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.
Updated•15 years ago
|
Attachment #420260 -
Flags: review?(jst) → review+
Assignee | ||
Comment 23•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Comment 24•15 years ago
|
||
Thank you so much Boris. Works great now.
Assignee | ||
Comment 25•15 years ago
|
||
Hey, I broke it; least I can do is fix it... ;)
Reporter | ||
Comment 27•15 years ago
|
||
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 → ---
Comment 28•15 years ago
|
||
(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
Assignee | ||
Comment 29•15 years ago
|
||
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.
Reporter | ||
Comment 30•15 years ago
|
||
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.
Description
•