[FIXr]After logging in to Fidelity, page is rendered but not visible

VERIFIED FIXED in mozilla1.8alpha5

Status

()

Core
Layout: View Rendering
P1
normal
VERIFIED FIXED
14 years ago
14 years ago

People

(Reporter: Curtis Williams, Assigned: bz)

Tracking

Trunk
mozilla1.8alpha5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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

14 years ago
Created attachment 165695 [details]
View Page Source
(Reporter)

Comment 2

14 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

14 years ago
Created attachment 165698 [details]
properly rendered screenshot
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
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...
Created attachment 166302 [details] [diff] [review]
Actually, more like this
Attachment #166300 - Attachment is obsolete: true
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+
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
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

14 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+
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha5

Updated

14 years ago
Flags: blocking1.8a5?
(Reporter)

Comment 13

14 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!
Curtis, thanks for confirming that that patch fixed the issue!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.