Last Comment Bug 224996 - <dialog> buttons have no label in remote XUL
: <dialog> buttons have no label in remote XUL
[good first bug]
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: x86 All
-- major with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Neil Deakin
Depends on:
Blocks: remote-xul
  Show dependency treegraph
Reported: 2003-11-07 09:07 PST by Jacob Page
Modified: 2011-10-06 16:11 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Work in progress (xpfe version) (5.92 KB, patch)
2005-09-28 02:30 PDT,
no flags Details | Diff | Splinter Review

Description User image Jacob Page 2003-11-07 09:07:24 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

In my XUL dialog, I could not get the built-in button captions to display.  The
"OK" and "Cancel" buttons are shown as empty.  The dialog example for the
XULPlanet web site
( also has the
same problem.  In both cases, the XUL is loaded using HTTP, not Chrome.  I am
unsure whether the same problem occurs using chrome.  Also, I am sure the
problem occurs on all platforms since I see the same results with Mozilla 1.5
under Windows 2000 and Linux.

I really hope that the response will not be that remote XUL is not a goal of  The Mozilla Amazon Browser really shows the power that XUL could
mean.  It's exciting technology.

Reproducible: Always

Steps to Reproduce:
1. Navigate to a XUL document with a dialog as the root element using the HTTP

Actual Results:  
A dialog appears with empty buttons.

Expected Results:  
I would expect Mozilla to display the proper captions for the platform and
locale, i.e. OK and Cancel for me.

I am using the modern theme, but I doubt button captions are part of the theme.
 Instead, I fear that the captions are DTD attributes that are not loaded unless
chrome is used.
Comment 1 User image 2003-11-07 09:30:47 PST
Known issue, <dialog> only works in chrome, because it needs permissions to
access the dialog labels.
Comment 2 User image Gervase Markham [:gerv] 2005-09-27 02:10:27 PDT
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Comment 3 User image 2005-09-27 16:24:30 PDT
I've got a patch that moves the labels from properties to entities if anyone
thinks it's worth supporting <dialog> in remote chrome.
Comment 4 User image Benjamin Smedberg [:bsmedberg] 2005-09-27 17:39:50 PDT
Neil, absolutely.
Comment 5 User image 2005-09-28 02:30:16 PDT
Created attachment 197680 [details] [diff] [review]
Work in progress (xpfe version)
Comment 6 User image Nickolay_Ponomarev 2006-01-06 07:19:05 PST
This is similar to bug 142502 for <wizard>, but I was unable to find an actual duplicate. Removing dupeme from whiteboard.
Comment 7 User image Pmash 2006-04-20 18:27:35 PDT
Can confirm that no Labels appear in remote sites.
Comment 8 User image Pmash 2006-04-20 18:33:51 PDT
Also wherever the dialog is opened or closed or a remote site via http://, the following error ir reported

 Error: uncaught exception: Permission denied to get property UnnamedClass.classes
Comment 9 User image Nickolay_Ponomarev 2006-04-21 02:45:53 PDT
There's no need for confirmation. We know what this bug is caused by. The way this issue should be fixed is described in comment 3 here, and there's a patch doing the same thing for <wizard> in bug 142502.

Adding [good first bug] to whiteboard, feel free to help fixing this.
Comment 10 User image Shriram (irc: Mavericks) Away 2009-03-08 20:02:02 PDT
I believe the patch mentioned in the previous comment should fix the issue. 
Has anyone got a chance to work on this yet?
Comment 11 User image Shriram (irc: Mavericks) Away 2011-10-03 08:23:07 PDT
It's been a while. Can anyone reproduce the issue now?
Comment 12 User image Benjamin Smedberg [:bsmedberg] 2011-10-03 09:46:02 PDT
Whether or not it can be reproduced now, we aren't going to be spending more time on remote XUL which is disabled by default. A lot has changed since 2005.
Comment 13 User image 2011-10-06 16:11:21 PDT
In the unlikely event that anyone wants to use remote xul, then yes, they still need to set their own dialog button captions.

Note You need to log in before you can comment on or make changes to this bug.