278859 - layout-debug issues in Firefox

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: Current trunk Firefox (before bsmedberg's command-line landing)

STEPS TO REPRODUCE:
1) Build debug Firefox with --enable-extensions=all
2) Try to run it with the -layoutdebug command-line option

EXPECTED RESULT: See layout debugger, with working menus and all.

ACTUAL RESULT: Totally horked UI.  Menus don't work.

This is pretty basic dogfood here... People are having to build SeaMonkey for
something as basic as running the layout regression tests.

I did some testing, and on first startup the menus that are present do work (the
others presumably reference overlays that don't exist in Firefox).  On second
startup I get some nice fastload errors:

###!!! ASSERTION: redundant multiplexed document?: 'docMapEntry->mString ==
nsnull', file /home/bzbarsky/mozilla/debug/mozilla/xpcom/io/nsFastLoadFile.cpp,
line 140

followed by layout being confused:

###!!! ASSERTION: initial containing block already created: 'nsnull ==
mInitialContainingBlock', file
/home/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp, line
8971

followed by XUL being confused:

###!!! ASSERTION: Popup set is already defined! Only 1 allowed.: 'Not Reached',
file
/home/bzbarsky/mozilla/debug/mozilla/layout/xul/base/src/nsRootBoxFrame.cpp,
line 296
###!!! ASSERTION: node in map twice: 'Not Reached', file
/home/bzbarsky/mozilla/debug/mozilla/layout/base/nsFrameManager.cpp, line 1897
###!!! ASSERTION: unexpected second call to SetInitialChildList: 'Not Reached',
file /home/bzbarsky/mozilla/debug/mozilla/layout/generic/nsContainerFrame.cpp,
line 109
###!!! ASSERTION: redundant multiplexed document?: 'docMapEntry->mString ==
nsnull', file /home/bzbarsky/mozilla/debug/mozilla/xpcom/io/nsFastLoadFile.cpp,
line 1403
###!!! ASSERTION: Bug 119310, perhaps overlayinfo referenced a overlay that
doesn't exist: 'mPlaceHolderRequest', file
/home/bzbarsky/mozilla/debug/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 2985
###!!! ASSERTION: redundant multiplexed document?: 'docMapEntry->mString ==
nsnull', file /home/bzbarsky/mozilla/debug/mozilla/xpcom/io/nsFastLoadFile.cpp,
line 1403
###!!! ASSERTION: forward references have already been resolved: 'Error', file
/home/bzbarsky/mozilla/debug/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 1321

Several repeats of this last one, then all of the above from the top, with lots
of copies of:

###!!! ASSERTION: node in map twice: 'Not Reached', file
/home/bzbarsky/mozilla/debug/mozilla/layout/base/nsFrameManager.cpp, line 1897

then (from nsBoxFrame.cpp):

WARNING: Warning add child failed!!

then (because the root session history is null, I bet):

WARNING: NS_ENSURE_TRUE(webnav) failed, file
/home/bzbarsky/mozilla/debug/mozilla/docshell/base/nsDocShell.cpp, line 2652

WARNING: NS_ENSURE_TRUE(aContent) failed, file
/home/bzbarsky/mozilla/debug/mozilla/layout/base/nsFrameManager.cpp, line 372

###!!! ASSERTION: Found more undisplayed content data after removal: 'context ==
nsnull', file
/home/bzbarsky/mozilla/debug/mozilla/layout/base/nsFrameManager.cpp, line 660

This last message is repeated half a dozen times.  Then all is quiet, and the UI
is dead.

Interestingly, after this I can't get the initial "ok" state no matter what I do
(I tried deleting the XUL.mfasl file and deleting all of .mozilla/firefox, but
neither helped).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Oh, this is trunk, of course.

Comment 2

[Hixie (not reading bugmail)]

brendan: top assertion is in fastload, so that seems a likely culprit. Could you
take a look? This is stopping Gecko devs from using Firefox for their work.

Comment 3

[Brendan Eich [:brendan]]

Hixie, we've been over this via IRC.  FastLoad has not regressed, but the way it
is used has.  Since no one else seems willing to dig in, I'll take a look with
dbaron's or bz's help tomorrow.  I expect to reassign this bug.

/be

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

I've been poking at fastload recently, so stealing from Brendan so I remember to
look at this.

Comment 5

[Darin Fisher]

BTW, I got layout-debug working just fine as a standalone XULRunner application
over the weekend.  I didn't have to edit any of the source files.  So, I figure
that these problems must be overlay related.

Comment 6

[Asaf Romano (gone)]

(In reply to comment #5)
> BTW, I got layout-debug working just fine as a standalone XULRunner application
> over the weekend.  I didn't have to edit any of the source files.  So, I figure
> that these problems must be overlay related.

Bug 243119 ?

Comment 7

[Hixie (not reading bugmail)]

Blake: Any news on this?

Comment 8

[Bernd]

I think <?xul-overlay href="chrome://communicator/content/tasksOverlay.xul"?>
should be <?xul-overlay href="chrome://browser/content/tasksOverlay.xul"?> to
get it running in firefox. There are a couple of references to communicator
which AFAIK will not work in firefox

Comment 9

[Boris Zbarsky [:bzbarsky]]

So with the checkin for bug 296102 the behavior here is slightly different.  The
menus no longer freeze up completely.  Some of the menu options work (eg "Dump
Frames").  Some others do not for no reason I can see (eg the paint flashing
one).  It's still not possible to run the regression tests because the relevant
submenus never come up.  But maybe they're actually defined in the overlays that
fail to load...

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #9)
> Some others do not for no reason I can see (eg the paint flashing
> one).

Paint flashing on GTK1 requires Caps-Lock; I don't think it's implemented on GTK2.

> It's still not possible to run the regression tests because the relevant
> submenus never come up.  But maybe they're actually defined in the overlays that
> fail to load...

They shouldn't be.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also, most of the overlay stuff can just be removed and the small parts that are
actually needed can be written by hand.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> I don't think it's implemented on GTK2.

That would do it... but the menuitem wasn't even reflecting the current pref value.

Comment 13

[Bernd]

just for the record: bryner did allready port layout-debug to firefox we only
need to build it. See
http://lxr.mozilla.org/mozilla/source/browser/extensions/layout-debug/

Comment 14

[Bernd]

Attachment: ff ui fixup

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

This patch does the following:
-Adds a Firefox-specific overlay so that it's possible to start the layout debugger from the Firefox tools menu
-Stops overlaying utilityOverlay.xul (all it did was populate the help menu in SeaMonkey and caused a "no chrome package" warning in Firefox)
-Removes the edit menu, which as far as I can tell is currently broken in both SeaMonkey and Firefox, and isn't really all that useful anyways.

I don't see any of the assertions mentioned earlier in this bug, and everything seems to work fine in a recent Firefox debug build. I've tested this patch with SeaMonkey to make sure all the menus that are still there still work. I think that once this patch lands, we should close this bug and file more specific bugs on any remaining issues.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 247748 [details] [diff] [review]
patch

r=dbaron.  Thanks for doing this.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

I've checked in that patch. I'm going to call this FIXED now, since I can't see any differences in the layout debugger when being used in Firefox or SeaMonkey, and can't reproduce the assertions mentioned earlier. New issues should go in other bugs, feel free to CC me.

mozilla/extensions/layout-debug/ui/content/contents.rdf 	1.3
mozilla/extensions/layout-debug/ui/content/layoutdebug-overlay.xul 	1.3
mozilla/extensions/layout-debug/ui/content/layoutdebug.xul 	1.5