bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

browser.frames.enabled = false cripples Account Settings dialog



MailNews Core
Account Manager
5 years ago
5 years ago


(Reporter: Hugh Allen, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)




5 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

Steps to reproduce:

Tools -> Options -> Advanced -> General -> Advanced Configuration -> Config Editor
Type "frames" (without quotes).
If "browser.frames.enabled" is set to True, double-click it to set it to False.
Esc twice to close dialogs.
Tools -> Account Settings.

Actual results:

Right pane of Account Settings dialog is blank.

Expected results:

Right pane should have various widgets to control settings.

Comment 1

5 years ago
Interesting observation, and also reproducible on SeaMonkey.
No duplicate found, confirming.

This may be a Core bug, XUL shouldn't depend on frame settings.
Component: Untriaged → Account Manager
Ever confirmed: true
Product: Thunderbird → MailNews Core
Version: 24 → Trunk

Comment 2

5 years ago
The issue may be rendered WFM if Core bug 729030 gets implemented and removes support for this preference, but no recent activity there.

Comment 3

5 years ago
Yes, the account manager uses an <iframe> element. I also think this should be solved in XUL base. Or is there any way we could work around it?

Comment 4

5 years ago
That pref also breaks the account central pane, and there may well be other places which I haven't tested (e.g. the customise toolbar code on the Mac uses an iframe, and I think the add-ons manager does too, and at one point feeds used to load in a frame, although they may have stopped doing this).

Although it would be possible to rewrite some of these not to use frames on a case-by-case basis I don't think we can realistically support this.

The preference activates via the nsIDocShell property allowSubframes so one approach would be to add script to force that property to true in the windows that needed it.

Another approach, but one that would not work for the add-ons manager, would be to ignore the preference in chrome windows.
You need to log in before you can comment on or make changes to this bug.