Closed Bug 537507 Opened 10 years ago Closed 10 years ago
Bookmarks and History Sidebars Empty on Initial Opening
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 <email@example.com> date: Thu Dec 31 14:07:57 2009 -0500 summary: Bug 528306 part 3. Hook up restyle processing to nsRefreshDriver. r=dbaron
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.
Oops sorry added regression back should have added that when I identified the regressor. Guess it's my fault.
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
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: 10 years ago → 10 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.