9601 - Wallet viewers come up blank (was Crash in raptorhtml.dll opening Wallet Contents)

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Paul MacQuiddy]

Overview Description: I am crashing on Windows accessing the Edit - Wallet -
Wallet Contents menu items. It is crashing in raptorhtml.dll, so assigning to
Rickg. It is *not* related to any of the dialogue issues that have been coming
up, because it happens even if the password database has already been opened.

Steps to Reproduce:
1) Launch Apprunner
2) Unlock signon database by going to Edit - Wallet - Change Password menu item
and hitting OK twice.
3) Goto Edit - Wallet - Wallet Contents

Actual Results: Immediate crash in raptorhtml.dll

Expected Results: Wallet Contents page should be displayed.

Build Date & Platform Bug Found: 071008 build, Win95

Additional Builds and Platforms Tested On: None yet (at home right now)


 Call Stack:    (Signature = nsCSSFrameConstructor::ContentRemoved 8edbc7cc)

   nsCSSFrameConstructor::ContentRemoved

[d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp,
line 4609]

   StyleSetImpl::ContentRemoved

[d:\builds\seamonkey\mozilla\layout\base\src\nsStyleSet.cpp, line 823]

   PresShell::ContentRemoved

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1737]

   nsDocument::ContentRemoved

[d:\builds\seamonkey\mozilla\layout\base\src\nsDocument.cpp, line 1616]

   nsHTMLDocument::ContentRemoved

[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line
776]

   nsDocument::Reset

[d:\builds\seamonkey\mozilla\layout\base\src\nsDocument.cpp, line 854]

   nsHTMLDocument::Reset

[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line
248]

   _PR_MD_UNLOCK
                                        [w95cv.c, line 328]

   nsHTMLDocument::Open

[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line
1413]

   NETLIB.DLL + 0x39920 (0x607d9920)

Comment 1

[Stephen P. Morse]

Whoever is going to look at this, I suggest you first pull version 1.1 of
WalletEditor.html from extensions/wallet/editor.  Then run nmake -f in that
directory.  (Or, if you don't want to run nmake, then manually copy this file
into the bin/res/samples directory.

Reason I'm saying this is that as soon as the tree opens for m9, I have a
completely new implementation of the wallet editor that I am about to check in.
And I don't know if that version will demonstrate the problem paulmac describes
or not.

Comment 2

[Paul MacQuiddy]

*** Bug 9695 has been marked as a duplicate of this bug. ***

Comment 3

[Paul MacQuiddy]

this is happening on all viewers on Unix and Windows, same stack trace in
raptorhtml.dll

Comment 4

[Stephen P. Morse]

This is affecting both wallet safe-fillin as well as wallet contents.  Both were
working last week so this is a recent regression.  If this is occuring in the M8
codebase, I would consider this to be an M8 showstopper.

Comment 5

[Paul MacQuiddy]

This was working in 7/9 evening build and then broke in 7/10 morning build. The
only suspicious thing I see is a hyatt checkin at 1:20 in the morning, so cc'ing
him.

Comment 6

[Paul MacQuiddy]

The easist way to reproduce this is to go to Edit - Wallet - Display Cookies

Comment 7

[chris hofmann]

putting on the m8 radar for a look.
rick, can you check this out?

Comment 8

[David Hyatt]

Fixed.

Comment 9

[Paul MacQuiddy]

hmmm, well it doesn't crash anymore, but all of the viewers (Display Cookies,
Safe Form Fill, Wallet Contents, Display Signons) come up blank, which was not
happening with Friday Evening's builds. That still kind of sucks. It looks like
sspitzer's fix at 12:41 today for bug 9698 fixed the crash, but that just was
masking another layout bug.

Re-opening and changing Summary to reflect new problems.

Using Monday evening build 071218 on Win95.

Comment 10

[David Hyatt]

I fixed the crash.  As for the page layout being screwed up, I have two
questions.

(1) Is morse using XUL files or HTML files?

(2) If morse is using XUL files, then has he been following the threads
regarding the two big changes to XUL syntax that landed over the past week and a
half on netscape.public.mozilla.xpfe?  If the answer is no, then morse's XUL
files have not been updated, and so it's only natural that their layout would be
screwed up.

Comment 11

[Paul MacQuiddy]

He is using HTML. For example, the Display Cookies menu item grabs
x86rel/res/samples/CookieViewer.html

Again, the layout had looked fine on Friday evening's builds.

Comment 12

[David Hyatt]

The dialogs need to be done in XUL, so that they can have the proper skin
applied (and therefore blend in with the rest of the dialogs in the product).

Anyway, I believe there's currently a bug where HTML opened as chrome doesn't
display.  Might be assigned to danm right now.  This sounds like a dup of that
bug.

We do plan to fix this bug, but people shouldn't be using HTML for dialogs or
chrome.  They should be using XUL to pick up intrinsic sizing, localizability,
skins, and other features you can't get using HTML as chrome.

Comment 13

[chris hofmann]

how long and involved a process is to to convert the viewers to xul?

reassigning bug to morse.

Comment 14

[Stephen P. Morse]

Attachment: Demo of failure independent of wallet viewers

Comment 15

[Stephen P. Morse]

I just created an attachment of a file that demonstrates that this bug has
nothing to do with dialogs within the product.  The attachment is the code that
is in the cookie viewer but slightly modified so that it doesn't use xpconnect.
If you go to view this page using the current 5.0 browser, it comes up blank.

Reassigning bug to hyatt.

Comment 16

[Stephen P. Morse]

Here's some more information.  The release build comes up blank as paulmac
reported.  On a debug build you get a series of assertion failures.  The first
such failure is as follows:

NTDLL! 77f76274()
nsDebug::PreCondition(const char * 0x01815a38, const char * 0x01815a14, const
char * 0x018159d8, int 4323) line 143 + 13 bytes
nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x0209bc40,
nsIPresContext * 0x019be890, nsIContent * 0x00000000, nsIContent * 0x024c8b9c,
int 0) line 4323 + 35 bytes
StyleSetImpl::ContentInserted(StyleSetImpl * const 0x0209bce0, nsIPresContext *
0x019be890, nsIContent * 0x00000000, nsIContent * 0x024c8b9c, int 0) line 804
PresShell::InitialReflow(PresShell * const 0x0209fcc0, int 9420, int 375) line
909
HTMLContentSink::StartLayout() line 2045
HTMLContentSink::OpenBody(HTMLContentSink * const 0x024c8c00, const
nsIParserNode & {...}) line 1799
CNavDTD::OpenBody(const nsIParserNode & {...}) line 2383 + 40 bytes
CNavDTD::OpenContainer(const nsIParserNode & {...}, int 1) line 2551 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x01aa6580, nsHTMLTag eHTMLTag_body,
nsIParserNode & {...}) line 1099 + 14 bytes
CNavDTD::HandleStartToken(CToken * 0x01aa6580) line 1409 + 31 bytes
NavDispatchTokenHandler(CToken * 0x01aa6580, nsIDTD * 0x024c9340) line 248 + 12
bytes
CTokenHandler::operator()(CToken * 0x01aa6580, nsIDTD * 0x024c9340) line 80 + 14
bytes
CNavDTD::HandleToken(CNavDTD * const 0x024c9340, CToken * 0x01aa6580, nsIParser
* 0x024c8d60) line 699 + 18 bytes
CNavDTD::BuildModel(CNavDTD * const 0x024c9340, nsIParser * 0x024c8d60,
nsITokenizer * 0x024ca530, nsITokenObserver * 0x00000000, nsIContentSink *
0x024c8c00) line 525 + 20 bytes
nsParser::BuildModel() line 933 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000) line 880 + 11 bytes
nsParser::Parse(nsString & {...}, void * 0x80000001, const nsString & {...}, int
0, int 0) line 764 + 13 bytes
nsHTMLDocument::ScriptWriteCommon(JSContext * 0x02076280, long * 0x01e00e70,
unsigned int 1, int 0) line 1515 + 150 bytes
nsHTMLDocument::Write(nsHTMLDocument * const 0x023b9f68, JSContext * 0x02076280,
long * 0x01e00e70, unsigned int 1) line 1529
NSHTMLDocumentWrite(JSContext * 0x02076280, JSObject * 0x00e69de8, unsigned int
1, long * 0x01e00e70, long * 0x0012e178) line 1141 + 24 bytes
js_Invoke(JSContext * 0x02076280, unsigned int 1, int 0) line 655 + 26 bytes
js_Interpret(JSContext * 0x02076280, long * 0x0012e9a4) line 2217 + 15 bytes
js_Invoke(JSContext * 0x02076280, unsigned int 0, int 0) line 671 + 13 bytes
js_Interpret(JSContext * 0x02076280, long * 0x0012f18c) line 2217 + 15 bytes
js_Invoke(JSContext * 0x02076280, unsigned int 0, int 0) line 671 + 13 bytes
js_Interpret(JSContext * 0x02076280, long * 0x0012f974) line 2217 + 15 bytes
js_Invoke(JSContext * 0x02076280, unsigned int 1, int 0) line 671 + 13 bytes
js_InternalCall(JSContext * 0x02076280, JSObject * 0x00dd6fd8, long 15004240,
unsigned int 1, long * 0x0012fab8, long * 0x0012fac0) line 749 + 15 bytes
JS_CallFunctionValue(JSContext * 0x02076280, JSObject * 0x00dd6fd8, long
15004240, unsigned int 1, long * 0x0012fab8, long * 0x0012fac0) line 2643 + 29
bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x024c2a20) line 97 + 34 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012fc84, nsIDOMEvent * * 0x0012fbfc, unsigned int 3, nsEventStatus &
nsEventStatus_eIgnore) line 965 + 21 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x02076444,
nsIPresContext & {...}, nsEvent * 0x0012fc84, nsIDOMEvent * * 0x0012fbfc,
unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2624
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x02074dc4, nsIDocumentLoader *
0x02074b20, nsIURI * 0x01bdadb0, int 0, nsIDocumentLoaderObserver * 0x02074dc4)
line 2948 + 34 bytes
nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x02074b20, int 0)
line 1030
nsDocLoaderImpl::LoadURLComplete(nsIURI * 0x01bdadb0, nsISupports * 0x01bc0de0,
int 0) line 1306
nsDocumentBindInfo::OnStopRequest(nsDocumentBindInfo * const 0x01bc0de0, nsIURI
* 0x01bdadb0, unsigned int 0, const unsigned short * 0x023bedf0) line 2037
OnStopRequestProxyEvent::HandleEvent(OnStopRequestProxyEvent * const 0x023bfd50)
line 593 + 45 bytes
StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x023bfd54) line 473 + 12
bytes
PL_HandleEvent(PLEvent * 0x023bfd54) line 493 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c3e930) line 454 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x992f079a, unsigned int 49372, unsigned int 0,
long 12839216) line 912 + 9 bytes
USER32! 77e71268()
00c

Comment 17

[Suresh Duddi (gone)]

People let us not confuse converting to XUL with this bug. We are tracking doing
the dialogs in XUL as another bug. This bug is the HTML doesn't work. And that
is a regression.

I am upping severity to blocker as testing cannot test any of the wallet
dialogs.

Comment 18

[David Hyatt]

Ok, sounds like it's a problem with HTML layout then, so I don't think it should
go to me.

Comment 19

[Peter Trudelle]

reassigning to layout owner

Comment 20

[Stephen P. Morse]

With the adage that "simpler is better" I have reduced my test case to a very
simple html file.  So ignore the attachment and just try to view a page
containing the html shown below.

One thing this simplification did show me is that the page is not really coming
up blank.  The frame borders are being displayed correctly (the bigger html file
had explicitly said not to display frame borders).  It's just that the contents
of the frame are not being displayed.

<HTML>
<HEAD>
  <SCRIPT>

    function loadCookies(){
      top.frames[0].document.open();
      top.frames[0].document.write(
        "<FORM name=fSelectCookie>" +
          "<SELECT> </SELECT>" +
        "</FORM>"
      );
      top.frames[0].document.close();
    }

  </SCRIPT>
</HEAD>
<FRAMESET ROWS = *,75 onLoad=loadCookies()>
  <FRAME SRC=about:blank>
  <FRAME SRC=about:blank>
</FRAMESET>

<NOFRAMES>
  <BODY> <P> </BODY>
</NOFRAMES>
</HTML>

Comment 21

[troy]

Chris, frameset problem

Comment 22

[Stephen P. Morse]

*** Bug 9773 has been marked as a duplicate of this bug. ***

Comment 23

[Eric Pollmann]

This is not a frameset bug.  Here is a reduced test case showing the same
problem:

<HTML>
<HEAD>
  <SCRIPT>
    function loadCookies(){
      top.document.open();
      top.document.write("New document");
      top.document.close();
    }
  </SCRIPT>
</HEAD>
<BODY ONLOAD="loadCookies()">This</BODY>
</HTML>

The document is not rewritten, and the following is dumped:
Assertion: "unexpected next reflow command frame" (nextFrame ==
mFrames.FirstChild()) at file nsHTMLFrame.cpp, line 206

Troy, Kipp, someone else want to take a look at this?

Comment 24

[Eric Pollmann]

Attachment: Reduced test case

Comment 25

[Eric Pollmann]

Also, after the document.write's, I dump the content model and get this:
...
  body refcount=3<
    Text refcount=3<New document>
...

But the frame model contains this:
...
Block(body)(1)@0x813ecf0 {120,120,9060,224} [state=00000014] sc=0x813ea38<
 line 0x8141190: count=1 state=clean,inline[0xc] {0,0,420,224} ca={0,0,420,224}<
  Text(0)@0x8141140[0,10,T][1]  {0,0,420,224} [state=00000024] sc=0x8140eb0<
   "\n\n  \n\nThis\n"
...

Comment 26

[David Hyatt]

Whoa. I forgot to check in my fix for this bug and Seth checked in a bad fix.
That's why this isn't working.  Let me check in the real fix, and then we can
close this out along with 9698.

Comment 27

[David Hyatt]

Ok, fix checked in to tip.  I mean it this time. ;)

Comment 28

[chris hofmann]

hyatt,  can you help cyeh get this on the branch?

http://cvs-mirror.mozilla.org/webtools/bonsai/cvsview2.cgi?diff_mode=context&whi
tespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/style/src&command=DIF
F_FRAMESET&root=/cvsroot&file=nsCSSFrameConstructor.cpp&rev1=1.153&rev2=1.154

Comment 29

[Chris Yeh]

it's on the branch already. i took the diff, and it was already in the file.

Comment 30

[Paul MacQuiddy]

This has been verified fixed on Mac/Linux/Windows with 7/14 M8 evening builds.
aaaaaaaah