107911 - Browser won't open if browser.frames.enabled is set to false - Error launching browser window:no XBL binding for browser

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[Peter Janes]

Looking through all.js, I found the intriguing preference
|browser.frames.enabled|.  Hoping this would enable a frame-free profile (the
pref was added for embedding), I turned it on.  After selecting the profile,
though, I got a dialog "Error launching browser window:no XBL binding for
browser", and the browser exited.

This would be really useful for testing pages for browser
compatibility/accessibility, but it's obviously not a high priority.

Linux trunk nightly -sea 2001102910.

Comment 1

[timeless]

see bug 69455

Comment 2

[harishd]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration -----

Comment 3

[Bill Mason]

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

Comment 4

[Bill Mason]

OS->All from the dup'ed bug.

Comment 5

[timeless]

reporter: a crash means that the app unexpectedly quit and your os tossed up a dialog saying that the 
app crashed. for windows XP it will offer to send a report to microsoft. mozilla will generally toss up its 
own talkback dialog. if you don't see such dialogs, then the app did not crash. it was merely fairly 
unhappy.

this distinction matters as I am able to use this preference to trigger a range of crashes, however the 
simple xbl dialog which you describe is not a crash and was merely something i got on my way to 
bigger and better things (crashers).

if you get a crash, please include a talkback incident id (which you can get by running 
components\talkback.exe).

if you don't get a crash, please don't say "a crash occurs".

Comment 6

[timeless]

EEK. Safari crossed two bugs. sorry.

Comment 7

[timeless]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040815

Note that on macos(x) this is not a fatal condition, you can continue using mozilla (mostly venkman, as 
most other components are fairly hosed) thanks to the global menubar. the description is still accurate, 
as the browser won't open.

Comment 8

[Sam Collett]

How can you find out what these error are? What does 'no XBL binding for
browser' mean and why would changing a preference cause this box to appear?

Is the browser capable of doing this - as it could prove extrememly useful for
testing purposes (as currently the only way to see how a page looks without
frames is to use Opera)?

Comment 9

[Carl Wickstrom]

I have tried to uninstall and reinstall and re-download everything all over 
again over the oher program, and nothing works.. it started doing this after I 
downloaded a theme... and changed the theme... now it won't open! HELP!

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

timeless, you were working on this a couple of weeks ago. Do you want to take
this  (or point to where you're working on this?). The actual fix for this
particular problem IIRC was removing several lines of code in
nsCSSFrameConstructor.cpp.

Comment 11

[Bernd]

Attachment: patch

Comment 12

[Bernd]

Attachment: more context

Comment 13

[Bernd]

I fail to see why that preference should control nsXULAtoms::editor  and
nsXULAtoms::browser. Enabling them again might be security relevant but I have
no clue about this.  At least with the patch seamonkey comes up as usual and
refuses to display frames.

Comment 14

[Bernd]

fixed by the checkin for bug 240129

Comment 15

[PikeUK]

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

Comment 16

[Matthias Versen [:Matti]]

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