Closed Bug 248004 Opened 21 years ago Closed 3 years ago

remote XUL windows ignore width and height attributes for XUL windows

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Milestone:
mozilla1.9alpha1

People

(Reporter: deepgloat, Unassigned)

References

Details

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
Closed: 21 years ago
Resolution: --- → INVALID
(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 → ---
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)...
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
Closed: 21 years ago → 21 years ago
Resolution: --- → WONTFIX
Summary: XUL windows ignore width, height and title attributes → remote XUL windows ignore width, height and title attributes
(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.
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.
Before anyone (including me!) makes any more claims, Mozilla folks should probably sit down and draw up consistent, up-to-date documentation.
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.
(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.
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 → ---
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
(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).
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."
Blocks: remote-xul
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.
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...
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');
Window titles have also been fixed in Mozilla 1.8 (with - Mozilla of course).
Priority: -- → P3
Target Milestone: mozilla1.8beta1 → mozilla1.9alpha
Not actively working on this, thought I still want it badly!
Assignee: benjamin → nobody
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets

Marking this as Resolved > Incomplete since the last activity on this issue was 13 years ago and it might not be relevant anymore. Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.

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