224996 - <dialog> buttons have no label in remote XUL

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Jacob Page]

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
(http://www.xulplanet.com/tutorials/xultu/examples/ex_11_2_1.xul) 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
mozilla.org.  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
protocol

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

[[e-mail]]

Known issue, <dialog> only works in chrome, because it needs permissions to
access the dialog labels.

Comment 2

[Gervase Markham [:gerv]]

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:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[[e-mail]]

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

[Benjamin Smedberg]

Neil, absolutely.

Comment 5

[[e-mail]]

Attachment: Work in progress (xpfe version)

Comment 6

[Nickolay_Ponomarev]

This is similar to bug 142502 for <wizard>, but I was unable to find an actual duplicate. Removing dupeme from whiteboard.

Comment 7

[Pmash]

Can confirm that no Labels appear in remote sites.

Comment 8

[Pmash]

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

[Nickolay_Ponomarev]

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

[Shriram (irc: Mavericks)]

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

[Shriram (irc: Mavericks)]

It's been a while. Can anyone reproduce the issue now?

Comment 12

[Benjamin Smedberg]

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

[[e-mail]]

In the unlikely event that anyone wants to use remote xul, then yes, they still need to set their own dialog button captions.