Bugzilla

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)...

Comment 4

•

20 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

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.

Comment 7

•

20 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

•

20 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

•

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.

Hish

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...

Toms Baugis

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');

neil@parkwaycc.co.uk

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