Closed
Bug 269402
Opened 20 years ago
Closed 20 years ago
[FIXr]After logging in to Fidelity, page is rendered but not visible
Categories
(Core :: Web Painting, defect, P1)
Core
Web Painting
Tracking
()
VERIFIED
FIXED
mozilla1.8alpha5
People
(Reporter: williamsca, Assigned: bzbarsky)
References
()
Details
Attachments
(3 files, 1 obsolete file)
82.55 KB,
text/html
|
Details | |
68.89 KB,
image/gif
|
Details | |
2.89 KB,
patch
|
roc
:
review+
roc
:
superreview+
asa
:
approval1.8a5+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041111 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041111 This is a change in behaviour in builds for about the last two weeks. At the moment, I am not sure which of the nightly builds this stopped working, but I will investigate and update this as soon as I can figure out which was the last good build. After going through a successful login to http://www.401k.com, Fidelity's web site, a summary page should be displayed for my account. What I am presented with is a page that is not visible, but all of the elements seem to be there. For instance, if I move the cursor around the page, it will turn into the finger over top of the places where links and buttons should be, but the page is entirely invisible. Because this page is rendered in IE, I know where the logout button is, and can click on it and successfully logout. So the elements are there and functioning, just not visible. I will be attaching a saved View | Page Source of the page in question. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
Looks like the last good trunk build is 2004102906. I am also attaching a screen shot of what the page should look like when properly rendered.
Reporter | ||
Comment 3•20 years ago
|
||
Assignee | ||
Comment 4•20 years ago
|
||
Looks like fallout from bug 244290... I see the following in a debug build on the "view page source" attachment (which doesn't paint the error pages like it should): ###!!! ASSERTION: Invalid batch count!: 'mUpdateBatchCnt >= 0', file /home/bzbarsky/mozilla/xlib/mozilla/view/src/nsViewManager.cpp, line 3335 ###!!! ASSERTION: Cannot process pending updates with refresh disabled: 'mRefreshEnabled', file /home/bzbarsky/mozilla/xlib/mozilla/view/src/nsViewManager.cpp, line 1607
Assignee: general → roc
Blocks: 269561
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout: View Rendering
Ever confirmed: true
QA Contact: general → ian
Assignee | ||
Comment 5•20 years ago
|
||
Ok, I can fix the issue with the "View Page Source" attachment (which may not be the same as the original bug, but I suspect it is...) by not setting mRootViewManager to |this| when mRootView is set to null by the destructor of said view. This does look like it causes us to possibly have a dangling mRootViewManager pointer in the child viewmanager. On the other hand, it looks like there are cases when our root view is killed off inside of a view update batch. In particular, ProcessReflowCommands() can call UnsuppressAndInvalidate(), which can call Show() on a document viewer, which kills off the old document viewer (along with the frame tree, the old root view, the presshell that was processing reflow commands, etc; see comments in UnsuppressAndInvalidate() after the call to Show()). If this is all happening in a subframe, we won't enable painting for the overall viewmanager tree...
Assignee | ||
Comment 6•20 years ago
|
||
Assignee | ||
Comment 7•20 years ago
|
||
Attachment #166300 -
Attachment is obsolete: true
Assignee | ||
Comment 8•20 years ago
|
||
Comment on attachment 166302 [details] [diff] [review] Actually, more like this It's a little messy, but as long as people are messing with our root view.... This holds a ref to mViewManager if it's not |this| and makes sure to never unset mViewManager. I'm tempted to release mRootViewManager in SetRootView() if it's not null and not |this| and aView is non-null. Or at least to assert that we don't have an mRootViewManager there...
Attachment #166302 -
Flags: superreview?(roc)
Attachment #166302 -
Flags: review?(roc)
Attachment #166302 -
Flags: superreview?(roc)
Attachment #166302 -
Flags: superreview+
Attachment #166302 -
Flags: review?(roc)
Attachment #166302 -
Flags: review+
Assignee | ||
Comment 9•20 years ago
|
||
I think it's worth taking this for 1.8a5... Robert, thoughts on the NS_RELEASE/assert part of comment 8?
Assignee: roc → bzbarsky
Flags: blocking1.8a5?
OS: Windows XP → All
Hardware: PC → All
Summary: After logging in to Fidelity, page is rendered but not visible → [FIXr]After logging in to Fidelity, page is rendered but not visible
Assignee | ||
Comment 10•20 years ago
|
||
Comment on attachment 166302 [details] [diff] [review] Actually, more like this This fixes a bunch of painting regressions on pages with frames... I don't think we want to ship 1.8a5 with those.
Attachment #166302 -
Flags: approval1.8a5?
Comment 11•20 years ago
|
||
Comment on attachment 166302 [details] [diff] [review] Actually, more like this a=asa for 1.8a5 checkin.
Attachment #166302 -
Flags: approval1.8a5? → approval1.8a5+
Assignee | ||
Comment 12•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?
Reporter | ||
Comment 13•20 years ago
|
||
I had been out on vacation, so I hadn't had a chance to check any recent builds. Just wanted to add a short note to confirm that this problem is resolved with last night's build. Thanks!
Assignee | ||
Comment 14•20 years ago
|
||
Curtis, thanks for confirming that that patch fixed the issue!
Status: RESOLVED → VERIFIED
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
•