218764 - <xml-stylesheet> processing instruction with href pointing to missing file makes some attributes get ignored in XUL file

Status: RESOLVED EXPIRED

(Core :: XML, defect)

Description

[Cedric. S.]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

In the example file below, if "toto.css" does not exist, width & height
attributes of the window object are ignored and the window takes the whole
screen (debug attribute is correctly taken into account).

There is no message anywhere about the missing file "toto.css".

This is visible when displying the window with "mozilla --chrome...", not when
opening it in a tab of the browser.

I am not sure if this is an XML problem or a XUL problem.

Its not blocking (just remove the line referencing inexistant file), but the
fact that attributes are ignored may denote a deeper problem ?

Reproducible: Always

Steps to Reproduce:
1. put the attached xul code in file (say test.xul) in on chrome directory
2. execute "mozilla --chrome chrome://mychrome/content/test.xul"
Actual Results:  
widht and height attributes are ignored on the window object and the window is
displayed full screen

Expected Results:  
the window is displayed at 640x480 ;
potentially a message on the console indicates that there is a reference to
a missing file in the PI

<?xml version="1.0"?>
<?xml-stylesheet href="toto.css" type="text/css"?>
<!-- toto.css does not exist in the same directory than the XUL file -->
<window
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
  debug="true" width="640px" height="480px">

</window>

Comment 1

[Boris Zbarsky [:bzbarsky]]

Does using "600" instead of "600px" change anything?

Does anything change if toto.css exists but is empty?

Comment 2

[Cedric. S.]

*** Bug 218810 has been marked as a duplicate of this bug. ***

Comment 3

[Cedric. S.]

When toto.css does not exist, whatever the width/height are, the window is
displayed full screen.

If toto.css is empty, the window is correctly displayed in all cases.

toto.css        | width    | height   | display 
---------------------------------------------------
dos not exist   | 640px    | 480px    | full screen
dos not exist   | 640      | 480      | full screen
empty           | 640px    | 480px    | 640x480
empty           | 640      | 480      | 640x480


Note that to perform the test, you have to kill mozilla between each run,
otherwise the behavior seems to follow a strange pattern (sometimes the window
is displayed full screen, sometimes not, for exatcly the same file -
nglayout.debug.disbale_xul_cache is at true in my config ).

Comment 4

[Cedric. S.]

The same kind of problem seems to happen when referencing an inexistent file
in a <?xul-overlay ...> Processing Intruction. In this case, Mozilla seems to
loop (like if it where downloding a page, but indefinitely).

Not sur if it(s the same bug or if I should open a new one.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Sounds like a different bug.  Please open that and mention the bug# in here.

Comment 6

[Cedric. S.]

new bug filed for the xul-overlay probleme :
http://bugzilla.mozilla.org/show_bug.cgi?id=221669

Comment 7

[Gervase Markham [:gerv]]

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 8

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.