remote XUL windows ignore width and height attributes for XUL windows

NEW
Unassigned

Status

()

Core
XUL
P3
major
14 years ago
3 months ago

People

(Reporter: Scott Gammans, Unassigned)

Tracking

Trunk
mozilla1.9alpha1
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616

XUL <window> elements ignore the "width", "height" and "title" attributes. These
attributes worked prior to Mozilla 1.7.

Reproducible: Always
Steps to Reproduce:
(1) Create two test files, index.html and xultest.xul:

****** index.html ******
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<body>
<input type="button" value="Load Test Window"
onclick="window.open('xultest.xul','xultest','chrome,resizable,centerscreen,dependent,dialog');">
</body>
</html>

****** xultest.xul ******
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin" type="text/css"?>
<!DOCTYPE window>
<window id="myid"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" title="My
Window" width="250px" height="250px">
    <script type="application/x-javascript" src="xultest.js"/>
    <box>
        <description>Hello world!</description>
    </box>
</window>

(2) Open index.html in Mozilla 1.7.

(3) Click the "Load Test Window" button. The XUL test window opens.
Actual Results:  
The XUL window title bar still shows "Mozilla", ignoring the "My Window" title
attribute, and the window opens quite large, ignoring the width and height
attributes of 250 pixels each.

Expected Results:  
The XUL window title bar should have changed its title to "My Window" and the
window should have opened with dimensions of 250x250 pixels.

This also seems to be affecting well-known remote XUL applications such as MAB
(http://mab.mozdev.org/)... I'm wondering if this is a "feature" that has been
added that breaks remote applications only, because dialogs like the Preferences
window in Mozilla itself still shows its title correctly and sizes itself
correctly. If this is indeed a new "feature", it's a Very Bad Feature.
untrusted content can't open windows with the "chrome" flag.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

14 years ago
(In reply to comment #1)
> untrusted content can't open windows with the "chrome" flag.
Yes you can. I verified this bug example before submitting it and it works fine
in Mozilla 1.7 (except for the broken "height", "width" and "title" attributes).
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 3

14 years ago
Incidentally, the "height", "width" and "title" attributes are working correctly
in Mozilla 1.8 alpha 1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8a1) Gecko/20040520)...

Comment 4

14 years ago
Perhaps Christian should have been more explicit. Using the |chrome| feature
does indeed not prevent the window from opening. But the feature will be
ignored, resulting in the symptoms you describe.

I'm certain we're all honest people here. But chrome bestows the power to abuse.
It doesn't work in untrusted script any longer. Your example works as you expect
if you preface the call to window.open with

netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserWrite')

which of course confronts the user with a scary dialog before granting you
license to do as you will. Remote XUL now needs to take this extra warning ste
before it can have that much control over its windows' appearance. Really,
remote XUL is supposed to be signed
(http://www.mozilla.org/projects/security/components/signed-scripts.html).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → WONTFIX
Summary: XUL windows ignore width, height and title attributes → remote XUL windows ignore width, height and title attributes
(Reporter)

Comment 5

14 years ago
(In reply to comment #4)
> Really, remote XUL is supposed to be signed
> (http://www.mozilla.org/projects/security/components/signed-scripts.html).

Really, those instructions are over two years old and DON'T WORK with Mozilla
1.7. It isn't very helpful to tell me I need to sign my remote XUL if there's no
easy (or difficult!) way to do it.

Comment 6

14 years ago
danm: as far as I'm concerned, the "width" and "height" properties should still
be honored, from the window.open call if specified, or from the XUL <window>
element. Secondly, I am trying to make usable remote XUL a viable option for
many web applications (using standard web-page privileges). We shouldn't
encourage people to use signed XUL/script and .enablePrivilege calls unless they
really need secure privileges.

deepgloat: if we made the width/height properties work correctly, is it a
problem for you that we don't honor the title attibute? You can still suppress
most, if not all, of the ordinary browser chrome decorations like the menubar,
statusbar, etc.

Comment 7

14 years ago
Before anyone (including me!) makes any more claims, Mozilla folks should
probably sit down and draw up consistent, up-to-date documentation.

Comment 8

14 years ago
Ugh. I don't necessarily mean documentation for signing packages. I mean
describing how remote XUL is going to work. The picture is somewhat fragmented
right now.
(Reporter)

Comment 9

14 years ago
(In reply to comment #6)
> deepgloat: if we made the width/height properties work correctly, is it a
> problem for you that we don't honor the title attibute? You can still suppress
> most, if not all, of the ordinary browser chrome decorations like the menubar,
> statusbar, etc.
Hi Benjamin: Yes, we can live with the title problem as long as the
document.title workaround is still available (setting the document.title
attribute works but appends "- Mozilla" onto the end of the title... which is OK
for us). Not being able to control window height and width is a deal-breaker,
though.

Dan M: I couldn't agree more that issues surrounding remote XUL need to be
addressed. I wish they *had* been addressed before our pilot apps started
breaking, but there you go. Also, we are VERY concerned about the situation with
signing remote XUL. If Mozilla developers keep adding restrictions to remote XUL
that can only be solved by signing it, all the while without addressing the
poorly-documented signing mechanism, XUL (and Mozilla) as a development platform
will be severely crippled. Thanks.

Comment 10

14 years ago
OK, I'm gonna reopen this and make it specifically about getting "width" and
"height" to work again. There's no reason why they shouldn't be allowed, subject
to the usual user preferences.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---

Comment 11

14 years ago
deepgloat: as a temporary workaround, you can always use the
width=foo,height=foo parameters to window.open().
Assignee: nobody → bsmedberg
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: remote XUL windows ignore width, height and title attributes → remote XUL windows ignore width and height attributes for XUL windows
Target Milestone: --- → mozilla1.8beta
(Reporter)

Comment 12

14 years ago
(In reply to comment #11)
> deepgloat: as a temporary workaround, you can always use the
> width=foo,height=foo parameters to window.open().
Thanks for reopening this, Benjamin. Unfortunately that workaround is no good
for us; we need to be able to control the dimensions of windows programmatically
(simple example: an error dialog that expands in height to show more details
when the user clicks the "Show Details" button). Also, having to specify the
height/width values in the function that opens a window violates the principle
of encapsulation (the opener of a window shouldn't have to its size when that
information can be encapsulated in the window's attributes).

Comment 13

14 years ago
Um Benjamin. I'd like to know what your plan is for allowing content windows to
take over aspects of the chrome, without using words like "horrible hack" and
"reintroducing security issues we thought we'd solved."
(Reporter)

Updated

14 years ago
Blocks: 133695

Comment 14

14 years ago
deepgloat: workaround #2 is to put onload="window.resizeToContent()" on your
<xul:window>.  This is controlled by the pref
Edit->Preferences->Advanced->Scripts & Plugins->Allow scripts to move or resize
existing windows (which is enabled by default, but users can turn it off).

danm: my "hack" would be to call sizeToContent on XUL windows when they are
window.open()ed and there is not an explicit width/height specified in the
window.open call.

Comment 15

14 years ago
window.resizeToContent() doesn'T work properly in 1.7. It resizes the window
about 10px to small after each call.
Regarding remote apps: Signing is ok as long as get somewhere a valid
documentation. I guess someone before stated that the current one doesn't work...

Comment 16

13 years ago
Below is a workaround to make mozilla/firefox size windows just like in old
times. Technique is simple - read the XUL as XML, get attributes, specified in
<window> tag and open the new window with those (simpleOpen function in this
case). Downside is that the file is read twice. Also that's real pitty that i
have simulate old behaviour instead of just relaying on built-in scripts.

function openWindow(fileName, attribs, width, height) {
  if (width && height){ 
    simpleOpen(fileName, attribs, width, height);
  } else { 
    // if width or height not specified, get them from file
    var xmlDoc = document.implementation.createDocument("", "", null);
    xmlDoc.async = false; // function needs to return opened window id, so no async
    xmlDoc.load(fileName); 
  
    elem=xmlDoc.getElementsByTagName("window")[0];
    
    width = width || elem.getAttribute('width');
    height = height || elem.getAttribute('height');
    
    return simpleOpen(fileName,attribs, width, height);
  }
}


Regarding window title - i put this line in my central .js file, so title gets
set automatically (with " - Firefox" at the end, of course):
document.title = window.document.documentElement.getAttribute('title');

Comment 17

13 years ago
Window titles have also been fixed in Mozilla 1.8 (with - Mozilla of course).

Updated

13 years ago
Priority: -- → P3
Target Milestone: mozilla1.8beta1 → mozilla1.9alpha

Comment 18

11 years ago
Not actively working on this, thought I still want it badly!
Assignee: benjamin → nobody

Updated

9 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.