42320 - Loading XBL from a web server

Status: VERIFIED FIXED

(Core :: XBL, defect, P3)

Description

[hand]

XUL and CSS loads fine from my web server

XBL doesn't.

I've tried the mind types text/xml and text/xbl
but neither work.

M16

Comment 1

[Stephen Walker]

[e-mail] do you have a url that we can use to test this? also, 
what's the build id that you found this bug on, not just m16?

Comment 2

[hand]

Is it possible to attach a ZIP file to this bug?  You need to open the file 
from your hard-drive to verify that it works, and then put it on a web server 
and verify it doesn't work from there.

I'm using build 2000060208.

Comment 3

[John Morrison]

Yes, you can attach a zip file. Select the radio button "Binary file 
(application/octet-stream)" when uploading, and note in the description
that it is a zip file (for best results).

Comment 4

[hand]

Attachment: XBL off a web-server problem

Comment 5

[Peter Trudelle]

no time left for N6, ->future

Comment 6

[David Hyatt]

John, could you verify that this is really a bug?  I would actually really like 
to fix this if it is.  

text/xml is the right mime type for an XML file to return (I think).  Maybe 
we're using a different MIME type now, and maybe that's the only reason it 
doesn't work.

Comment 7

[John Morrison]

While bugzilla was down, I set up a testcase at :

   http://jrgm/testcase/xbl/remote-xbl/001/test.xul

The same three files (xml/xul/css), when loaded locallyt from a chrome directory
seem to work correctly (except for the same namespace error ... you'll have to
refresh my menory on what I have wrong there).

I will also look at the testcase that [e-mail] attached (but
here's one for now).

At any rate, in a debug build from this evening, the testcase at jrgm results
in four assertions:

###!!! ASSERTION: Failed loading an XBL document for content node.: 'Error',
file d:\mozilla\mozilla\layout\xbl\src\nsXBLService.cpp, line 253
WARNING: Invalid XUL tag encountered in file. Perhaps you used the wrong namespace?
The tag name is mywidget, file
d:\mozilla\mozilla\layout\html\style\src\nsCSSFrameConstructor.cpp, line 6103
###!!! ASSERTION: Failed loading an XBL document for content node.: 'Error',
file d:\mozilla\mozilla\layout\xbl\src\nsXBLService.cpp, line 253
Document: Done (4.438 secs)
Document http://jrgm/testcase/xbl/remote-xbl/001/test.xul loaded successfully
###!!! ASSERTION: NS_ENSURE_TRUE(aListener) failed: 'aListener', file
d:\mozilla\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp, line 1213
###!!! ASSERTION: NS_ENSURE_TRUE(aListener) failed: 'aListener', file
d:\mozilla\mozilla\netwerk\protocol\http\src\nsHTTPChannel.cpp, line 1213

Comment 8

[John Morrison]

By the way:
 1) The three files (xbl/xul/css) required can be viewed as a single text file
     at  http://jrgm/testcase/xbl/remote-xbl/001/files.txt
    (but mozilla interprets that text as XML not plain text, so use Nav4 to
     view it [... gotta go reopen a bug on parser].
 2) The HTTP headers sent from that web server say that the content-type is
      Content-Type: text/xml   for the .xml file (xbl content)
      Content-Type: text/xul   for the .xul file
      Content-Type: text/css   for the .css file

Comment 9

[John Morrison]

[e-mail] -- if you want a copy of my testcase, ping me and I
will attach the files to this bug report.

Comment 10

[David Hyatt]

Nominating for nsbeta3.  Remote XBL is completely useless without this being 
fixed.

Comment 11

[David Hyatt]

Ok, I understand the problem and am about halfway to a fix.  Stay tuned.

Comment 12

[David Hyatt]

Thanks for the test case, jrgm.  It was perfect!

Comment 13

[David Hyatt]

Fixed. Run the test case to verify.  Craft any other insidious test cases as 
desired.

Comment 14

[John Morrison]

Insidious. Most excellent adjective!

Comment 15

[hand]

John:

Please do attach the test case.

Much appreciated.

Comment 16

[John Morrison]

Attachment: my testcase (which in the end is pretty similar to John (hand)) [.zip file]

Comment 17

[hand]

It works great - you people have been a great help.

Many Thanks

Comment 18

[John Morrison]

verified fixed mac/linux/win32 20000808nn builds -- thanks for filing this bug!

Comment 19

[Axel Hecht]

Hi,
I am afraid I see regression here. Or is there a good difference between
loading xbl from local disk instead of webserver?

I did a 
truss -topen ./mozilla-bin
on solaris with the following output (reports OS trying to open files, shows
bad filenames as failed request):

open64("/tmp/optim/dist/bin/chrome/skins/modern/global/skin/menu-arrow-hover.gif",
O_RDONLY) = 16
open64("/tmp/optim/dist/bin/chrome/skins/modern/global/skin/animthrob.gif",
O_RDONLY) = 16
open64("/home/ah/projekte/mozilla/js_shell/content/test.xul", O_RDONLY) = 17
open64("/tmp/optim/dist/bin/chrome/skins/modern/navigator/skin/back.gif",
O_RDONLY) = 17
open64("/home/ah/projekte/mozilla/js_shell/content/test.css", O_RDONLY) = 17
Document file:///home/ah/projekte/mozilla/js_shell/content/test.xul loaded
successfully

this is the test case as attached, opened with file://home/ah/...../test.xul

Any help on this one?

Axel

Comment 20

[David Hyatt]

All debug demos are on a Web server and work.  I'm inclined to close this out. 

Comment 21

[Axel Hecht]

Thanx Hyatt for the quick response.
The attached files have a
  behavior: url('test.xml#mywidget');
instead of
  -moz-binding: url('test.xml#mywidget');
For all those falling in this trap later, the current demos are on
http://www.shadowland.org/xbl/test0/test.[xul,css,xml]

marking verified, saved my, hrm, night.

Axel