<dialog> buttons have no label in remote XUL

RESOLVED WONTFIX

Status

()

Core
XUL
--
major
RESOLVED WONTFIX
14 years ago
6 years ago

People

(Reporter: Jacob Page, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [good first bug], URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

14 years ago
Known issue, <dialog> only works in chrome, because it needs permissions to
access the dialog labels.
Whiteboard: DUPME
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

12 years ago
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

12 years ago
Neil, absolutely.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

12 years ago
Created attachment 197680 [details] [diff] [review]
Work in progress (xpfe version)

Comment 6

12 years ago
This is similar to bug 142502 for <wizard>, but I was unable to find an actual duplicate. Removing dupeme from whiteboard.
Blocks: 133695
Summary: XUL dialog buttons have no caption → <dialog> buttons have no label in remote XUL
Whiteboard: DUPME

Comment 7

12 years ago
Can confirm that no Labels appear in remote sites.

Comment 8

12 years ago
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

12 years ago
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.
Assignee: hyatt → nobody
QA Contact: shrir → xptoolkit.xul
Whiteboard: [good first bug]

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
I believe the patch mentioned in the previous comment should fix the issue. 
Has anyone got a chance to work on this yet?
It's been a while. Can anyone reproduce the issue now?

Comment 12

6 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
In the unlikely event that anyone wants to use remote xul, then yes, they still need to set their own dialog button captions.
You need to log in before you can comment on or make changes to this bug.