Closed
Bug 248004
Opened 20 years ago
Closed 3 years ago
remote XUL windows ignore width and height attributes for XUL windows
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
INCOMPLETE
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.
Comment 1•20 years ago
|
||
untrusted content can't open windows with the "chrome" flag.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•20 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•20 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)...
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: 20 years ago → 20 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•20 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•20 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.
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.
Reporter | ||
Comment 9•20 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•20 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•20 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•20 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•20 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•20 years ago
|
Blocks: remote-xul
Comment 14•20 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•20 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•20 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•20 years ago
|
||
Window titles have also been fixed in Mozilla 1.8 (with - Mozilla of course).
Updated•19 years ago
|
Priority: -- → P3
Target Milestone: mozilla1.8beta1 → mozilla1.9alpha
Comment 18•17 years ago
|
||
Not actively working on this, thought I still want it badly!
Assignee: benjamin → nobody
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
Comment 19•3 years ago
|
||
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: 20 years ago → 3 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•