Closed Bug 921727 Opened 11 years ago Closed 4 years ago

browser.frames.enabled = false cripples Account Settings dialog

Categories

(MailNews Core :: Account Manager, defect)

Product:
MailNews Core
Component:
Account Manager
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: hufraser, Unassigned)

Details

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.
Interesting observation, and also reproducible on SeaMonkey.
No duplicate found, confirming.

This may be a Core bug, XUL shouldn't depend on frame settings.
Status: UNCONFIRMED → NEW
Component: Untriaged → Account Manager
Ever confirmed: true
Product: Thunderbird → MailNews Core
Version: 24 → Trunk
The issue may be rendered WFM if Core bug 729030 gets implemented and removes support for this preference, but no recent activity there.
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?
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.

browser.frames.enabled is gone. See bug 1013457.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.