Closed
Bug 267557
Opened 20 years ago
Closed 20 years ago
[FIXr]several websites don't refresh unless I move my mouse
Categories
(Core :: Web Painting, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla1.8alpha5
People
(Reporter: pstevereynolds, Assigned: bzbarsky)
References
()
Details
(Keywords: regression, top100)
Attachments
(3 files)
2.02 KB,
text/html
|
Details | |
1.41 KB,
patch
|
bzbarsky
:
review-
bzbarsky
:
superreview-
|
Details | Diff | Splinter Review |
956 bytes,
patch
|
asa
:
approval1.8a5+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041103 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041103 Yahoo, Hotmail, Gmail, operamail and our internal email web server are most noticeable. When I go to these sites, they intially come up properly. But when I click to read an email, the email doesn't appear unless I move the mouse. Reproducible: Always Steps to Reproduce: 1. go to gmail (or some mail system with several emails ready to be read) 2. click on an email, get a blank screen 3. move mouse and the screen appears. Actual Results: nearly blank screen Expected Results: a properly updated screen should appear.
Assignee | ||
Comment 1•20 years ago
|
||
Is this a recent regression? If so, can you pin down when this started?
Assignee | ||
Comment 2•20 years ago
|
||
Steve says this started between Build 2004-11-03-06 and 2004-11-04-06. Checkins for that range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-11-03+06%3A00%3A00&maxdate=2004-11-04+06%3A00%3A00&cvsroot=%2Fcvsroot None of these really jump out at me as being likely to have caused this.... Martijn, can you reproduce this, by any chance? You have Windows, right?
Comment 3•20 years ago
|
||
(In reply to comment #2) > Martijn, can you reproduce this, by any chance? You have Windows, right? I have Windows, but I can't reproduce this bug, using gmail. Used a Mozilla 2004-11-14 build and Firefox 2004-11-15 and 2004-11-04 builds in trying to reproduce.
Comment 4•20 years ago
|
||
Hmm, actually I think I see this same or maybe related problem at http://www.blogger.com when I add a new blog post. There, I can reproduce the bug 100% of the time. Steps to reproduce: - Go to http://www.blogger.com/start - Sign in at your account (if you don't have any, you have to create one) - Click on the "+" under "New Post" - Press "Publish Post". After that don't move you mouse at all. After that the bottom page is blank, until you move the mouse. After that you get to see "Your blog published successfully." etc. This seems to be the regression range for me for this issue: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041030 Firefox/0.9.1+ 8:18am Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041031 Firefox/0.9.1+ 7:39am http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-10-30+08%3A00%3A00&maxdate=2004-10-31+08%3A00%3A00&cvsroot=%2Fcvsroot
Comment 5•20 years ago
|
||
Forget about the most of comment 4 (except the regression range perhaps). I think I'll be able to make a testcase which shows the bug. Hang on for a moment.
Comment 6•20 years ago
|
||
This testcase shows the bug 100% reproducable for me. Two characteristics that are needed to trigger the bug: - The bugged page has to be in a (i)frame. - The bugged page has to have an image inside it. Comment 4 is probably totally ****. With the testcase I get this regression range: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041029 Firefox/0.9.1+ 7:22am Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a5) Gecko/20041030 Firefox/0.9.1+ 8:18am http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-10-29+07%3A00%3A00&maxdate=2004-10-30+09%3A00%3A00&cvsroot=%2Fcvsroot
Assignee | ||
Comment 7•20 years ago
|
||
OK, this looks like a regression from bug 244290. The iframe is needed so we hav a viewmanager tree; the image, I suspect, causes us to actually make use of the paint suppression timer or something.... I can reproduce this reliably without the mouse thing if I disable the nsEventStateManager::FlushPendingEvents stuff that runs on mouse moves (that is, if I do that the iframe simply never paints). Martijn, thank you for the testcase!
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout: View Rendering
Ever confirmed: true
Assignee | ||
Comment 8•20 years ago
|
||
OK, I tracked this about a bit. One issue I see offhand is the DisableRefresh() call on the viewmanager in PresShell::Destroy. This disabled refresh on the entire viewmanager tree, and I see no corresponding EnableRefresh(). I bet if the refresh thing were a counter, not a boolean, it would never get reenabled at all. As it is, the next time we do a disable/enable cycle it gets reenabled. Robert, I'm really not quite sure what the best solution here is. I really don't like having the EnableRefresh/DisableRefresh api... Perhaps the presshell should use a view update batch in ::Destroy? As long as we're not unsetting the mRootViewManager pointer (bug 269402) that should be ok... Alternately, we could just EnableRefresh() here. I _would_ like to make the refresh thing a counter, to better catch errors like this, however.
Assignee: general → roc
QA Contact: general → ian
Assignee | ||
Comment 9•20 years ago
|
||
Oh, so to make it clear, if I comment out the DisableRefresh in PresShell::Destroy it fixes things on the testcase for me.
> Robert, I'm really not quite sure what the best solution here is. I really > don't like having the EnableRefresh/DisableRefresh api... Agreed. I traced the DisableRefresh call in PresShell::Destroy to see when and why it was introduced. It was originally added to PresShell::~PresShell() by kipp; the CVS comment just says "3.125 <kipp@netscape.com> 1999-04-29 17:08 Disable rendering during presentation tear down". Sigh. It clearly isn't the right thing to do when Enable/DisableRefresh is global. I say we take it out and see what the damage is.
Assignee | ||
Comment 11•20 years ago
|
||
The other option is to re-enable refresh... I'm not sure which is more dangerous for 1.8a5...
Assignee | ||
Comment 12•20 years ago
|
||
I checked that this also works....
Assignee | ||
Comment 13•20 years ago
|
||
Comment on attachment 166416 [details] [diff] [review] Patch to reenable refresh Robert, if you do prefer that I just take out the DisableRefresh, let me know and I will.
Attachment #166416 -
Flags: superreview?(roc)
Attachment #166416 -
Flags: review?(roc)
Comment 14•20 years ago
|
||
The patch does not seem to fix bug 270925. The bug also occurs on several sites that uses <frame>s, http://www.cdon.se for example (the patch did not fix those either).
OS: Windows XP → All
Updated•20 years ago
|
Keywords: regression
Comment 15•20 years ago
|
||
The patch does not fix the testcase either for me...
Assignee | ||
Comment 16•20 years ago
|
||
See comment 8 -- this patch depends on the patch in bug 269402.
Depends on: 269402
Comment 17•20 years ago
|
||
*** Bug 270925 has been marked as a duplicate of this bug. ***
> Robert, if you do prefer that I just take out the DisableRefresh, let me know
> and I will.
I think we should do that and find out why it's needed :-). If it is needed then
we fix the underlying problem. r+sr for that.
Assignee | ||
Comment 19•20 years ago
|
||
Attachment #166416 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Attachment #166416 -
Attachment is obsolete: false
Attachment #166416 -
Flags: superreview?(roc)
Attachment #166416 -
Flags: superreview-
Attachment #166416 -
Flags: review?(roc)
Attachment #166416 -
Flags: review-
Assignee | ||
Comment 20•20 years ago
|
||
Comment on attachment 166720 [details] [diff] [review] Patch to just remove DisableRefresh() call This has reviews from Robert, and fixes a bunch of painting regressions on pages with frames. It's reasonably safe as changes go, I believe.
Attachment #166720 -
Flags: approval1.8a5?
Assignee | ||
Updated•20 years ago
|
Assignee: roc → bzbarsky
Summary: several websites don't refresh unless I move my mouse → [FIXr]several websites don't refresh unless I move my mouse
Comment 21•20 years ago
|
||
Comment on attachment 166720 [details] [diff] [review] Patch to just remove DisableRefresh() call a=asa for 1.8a5 checkin.
Attachment #166720 -
Flags: approval1.8a5? → approval1.8a5+
Assignee | ||
Comment 22•20 years ago
|
||
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 20 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha5
Updated•20 years ago
|
Flags: blocking1.8a5?
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•