compose window does not load (prompts for download) [XUL cache??]




16 years ago
4 years ago


(Reporter: James Rome, Unassigned)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(3 attachments)



16 years ago
On the 2002022103 build, I tried to reply to mail or compose mail. A full screen
blank window pops up and starts downloading a file called messengercompose.xul

But I haven't a clue what to do with this file and where to put it! I can't send

Why has this changed suddenly (in the p[ast week).
wfm with win2k build 20020222

Comment 2

16 years ago
I rebooted, and that behaviour disappeared!  Most wierd.

Comment 3

16 years ago
I spoke too soon. It worked once when I started Mozilla. But then after I opened
my IMAP mailbox, the same screen pops up. I can't do anything.

Win2k, all the latest patches and SPs.

Where do I put that .xul file?

Comment 4

16 years ago
The 2/16 build also shows this behavior (on 2 machines). But Netscape 6.2.1 lets
me send mail. I just applied the latest hotfixes for win2k. Could they be having
some effect?
Something went wrong with the installation apparently! All those XUL files are
part of JAR file. Try doing a clean install.

Comment 6

16 years ago
I uninstalled, deleted the mozilla directory, reinstalled, and the same thing

The file should be there (in the jar) because when I start Mail/News, if I
compose before opening my imap folder it works.

But as soon as I open my inbox, the xul file gets downloaded!

Comment 7

16 years ago
ok whatever is causing this, I'm seeing it with build 2002022103 win32 installer
trunk. Confirming. I'll attached a screenshot. It seems to be a problem with not
handling xul windows from xul cache properly.
Ever confirmed: true
Keywords: mozilla0.9.9, regression
cc'ing Hyatt

Comment 9

16 years ago
Created attachment 70993 [details]

Comment 10

16 years ago
changing summary from:
  Can no longer compose mail
  compose window does not load (prompts for download)
Summary: Can no longer compose mail → compose window does not load (prompts for download)


16 years ago
QA Contact: sheelar → esther

Comment 11

16 years ago
since it offered to "save the file", I allowed it. and guess what? Its an empty
file!! Could the XUL cache be failing somewhere? I'll turn off XUL cache and see
if it works.

Comment 12

16 years ago
I disabled XUL cache and the problem disappeared. But I can't seem to send mail
via smtp (news posting works though), guess this is another bug.

Comment 13

16 years ago
this is a smoketest blocker.
Keywords: smoketest

Comment 14

16 years ago
This is a regression, since it all worked before. I was wondering if my bug
about saving .exe files
had a fix put in that changed this!

Comment 15

16 years ago
I'm seeing this problem on Linux as well: build 2002022408
If I have XUL cache enabled, I'm asked to save the XUL file upon opening
MailNews for the second time.

Can somebody add 'XUL cache' to summary because that's what I was searching for
when I didn't find this bug.
Also OS -> All.


16 years ago
OS: Windows 2000 → All
Summary: compose window does not load (prompts for download) → compose window does not load (prompts for download) [XUL cache??]

Comment 16

16 years ago
sending to XUL
Assignee: ducarroz → hyatt
Component: Composition → XP Toolkit/Widgets: XUL
Product: MailNews → Browser
QA Contact: esther → jrgm

Comment 17

16 years ago
This happened sometime between 02/19/2002 06:00:00 and 02/20/2002 06:00:00

Comment 18

16 years ago
After switching theme to Classic, the problem disappeared.
Switching back to Modern did not make it appear.

I compared the two profiles: the working and the one exhibiting this bug.
The file that makes the problem appear is chrome/chrome.rdf

Should I attach the two chrome.rdf files? One that works perfectly and the one
that exhibits the problem?
vadim, yes, please attach those chrome.rdf files.

is this still a smoketest blocker?

Comment 20

16 years ago
Created attachment 71358 [details]
bad chrome.rdf

Comment 21

16 years ago
Created attachment 71359 [details]
good chrome

Comment 22

16 years ago
In my case, problem only happens with the Orbit3 theme with XUL cache enabled. I
got rid of my chrome.rdf file, restarted, reinstalled orbit3 but no luck. Whats
odd is that the very first compose window that I bring up is fine. Subsequent
ones are the problem...hhhmm I wonder if its because of max_recycled_windows pref?

Comment 23

16 years ago

Try simply Applying Classic and then Applying Orbit 3 again.
That's what fixed it for me. I didn't mess with chrome.rdf manually.

Comment 24

16 years ago

Nope that didn't fix it for me. (not to mention that Mozilla crashed 2-3 times
in the process of changing themes)

More playing with the mail.compose.max_recyled pref. If I have it set to 2 then
I can always open up 1 compose window. It fails if I try to open a second
compose window if the 1st one is open.

Comment 25

16 years ago
Well, using the classic theme, things seem to work. But when I switch back to
the 0.98 LittleMozilla, it dies again.

I've seen such weirdness from LittleMozilla if it doesn't completely download
correctly and install itself all the way.

Also its possible there where some significant changes from those theme release
dates and mozilla's code 0.9.8 code to a latest nightly as noted in here around
the 19th.. ie they dont line-up is what I'm saying.

Comment 27

16 years ago
*** Bug 128052 has been marked as a duplicate of this bug. ***

Comment 28

16 years ago
bug 126113 (smoketest blocker, too) seems be a chome.rdf-related issue - is it
somehow related to this bug ?

Comment 29

16 years ago
I had this problem on 2/26.  Either clicking compose directly or
clicking a mailto: link.

It disappeared when I installed yesterday's latest nightly last 
night ( 2/27 - I think 11:?? win32 )  FWIW both before & after 
were using Lo-Fi theme

Comment 30

16 years ago
Is this happening to everyone using today's verification builds of Mozilla (not
Little Mozilla, whatever that is), with either Classic or Modern themes?  

Comment 31

16 years ago
Someone said hyatt is out today. Reassigning to hewitt. Hewitt, can you pls take
a look into this. If you are not the right owner, please re-assign. Thanks!!
Assignee: hyatt → hewitt

Comment 32

16 years ago
Adding JFD, to cc list. 

Comment 33

16 years ago
That mime type in the dialog: mozilla.application/cached-xul looks a little odd.
 We have code in place somewhere that makes sure we do the right thing with xul
loaded from jar: URLs.  Maybe something has changed here that is confusing that

Comment 34

16 years ago
Hyatt is listed as giving a presentation at all hands meeting today.
I can't get ahold of him or hewitt.

Comment 35

16 years ago
*** Bug 128308 has been marked as a duplicate of this bug. ***

Comment 36

16 years ago
I see this bug only in Orbit3 theme. I've never seen in Modern or Classic but I
think other people have. I can always reproduce this bug in Orbit3 so if you
want a snapshot of chrome.rdf or something, I can put it up.

Comment 37

16 years ago
could this possibly be due to the current builds needing to have a new
skinversion number?  it could be that these skins are not technically supposed
to work on this version of mozilla, and the skinver would prevent those skins
from being used until they got updated.  Just a though..
  For instance:

Skins built to work on moz 0.9.4 will definitely break on current builds. But
perhaps this isnt the real issue.   

Little Mozilla is a skin available from one of the theme sites, I have not seen
this on Modern or Classic at all, w2k.

Comment 39

16 years ago
hewitt is out at a meeting from 9:30 till 5:30 today. You'll need to tag someone
else on Nav to help with this. Peter can you help find a resource to look at this?
why is this holding the tree closed if it's only 3rd party skins?

Comment 41

16 years ago
--smoketest. No point in holding the whole tree for this.

This is reproducible when using, e.g., orbit3 and doing message compose. 
It regressed between late afternoon 02/19 and 02/20 8am builds (a lot of 
changes in that period). 

Workaround is to switch to modern or classic (right?), or, worst case, 
delete the chrome.rdf and <skin>.jar from your profile directory.
Keywords: smoketest

Comment 42

16 years ago
I do not see this in modern skin either.
Since there is a workaround reducing the severity.
Severity: blocker → critical

Comment 43

16 years ago
I was seeing this on Modern, but I had other themes installed.
So it's not only 3rd party.
*** Bug 128445 has been marked as a duplicate of this bug. ***

Comment 45

16 years ago
*** Bug 129380 has been marked as a duplicate of this bug. ***

Comment 46

16 years ago
Ugh. Never mind. I was using Orbit which looks almost exactly like Modern. 
Yeah. It's third party only.

Comment 47

16 years ago
*** Bug 128781 has been marked as a duplicate of this bug. ***
No longer blocks: 127533
*** Bug 127533 has been marked as a duplicate of this bug. ***
nominating, since this breaks third-party themes
Blocks: 127533
Keywords: mozilla1.0, nsbeta1

Comment 50

16 years ago
Nav triage team needs info: How can we be at fault only third party themes are
broken?  If Modern and Classic work okay with recent builds, then aren't the
third-party theme authors responsible for making their themes work with the build?  
Whiteboard: [need info]

Comment 51

16 years ago
Do you inform third party theme creators what has changed to break their themes?

And we badly need a "supported" theme such as LittleMozilla) that takes up a lot
less desktop. I personally don't care what the theme looks like, so long as it
is small!

Comment 52

16 years ago
Good question. I'm not sure we'd necessarily know what breaks their themes, and
we certainly cannot afford to test all of them. How do theme authors (including
Modern & Classic) currently find out about changes that affect them?  If they
are trying to actively adapt to ongoing changes in the nightlies, then there has
to be some means set up.  Is there a way to automate monitoring of checkins to
the supported default themes?
If classic and modern are all we care about, we don't support themes.

Therefore, since last fall, we've had a deal (at least asa and I thought we
did): hyatt or hewitt or whoever is leading the XUL-change charge that breaks
themes writes up a release note for each milestone telling theme authors what
they need to do to keep their themes working.

That's the minimum communication necessary; postings to m.xpfe as changes go in
help those theme authors who try to track nightlies, so as to avoid too much
work at a milestone release, playing "catch up".

I have not checked to see whether this deal is being kept.  It should be, it's
the minimum for good ownership.


Comment 54

16 years ago
It would be best if we could use these same channels for all themes, including
Classic & Modern.  I think that is true for those maintining support in the
nightlies via m.xpfe, but perhaps a milestone release note has been overlooked
in the transfer of XPToolkit ownership?

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

Comment 56

16 years ago
nsbeta1- per Nav triage team, since there is non checkin required for MachV.
Sounds like this deserves separate bugs for each broken skin, does anyone who to
reassign this to?

Joe, as the new XPToolkit/XUL lead, I'm sure you'll honor the agreement made
with to provide the necessary release notes needed by theme authors
to update their themes each milestone.  And please ensure this comes out of your
*paid* working time, not your free time. ;-)
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [need info]

Comment 57

16 years ago
*** Bug 130608 has been marked as a duplicate of this bug. ***
*** Bug 130391 has been marked as a duplicate of this bug. ***

Comment 59

16 years ago
*** Bug 131552 has been marked as a duplicate of this bug. ***

Comment 60

16 years ago
I get the same message as the original screen shot, but from "What should 
Mozilla do with this file?" down, there is nothing, and it comes up when 
Navigator is started. I only have the option to close the message and Mozilla 
Quick Launch freezes up.
I'm running version 1.1 on Win98 using Modern theme

Comment 61

15 years ago
We see this problem with our 3rd party chrome also.

With Mozilla 1.0, xul cache enabled and loading a page from a jar file that 
contains a broken link to e.g. a stylesheet or dtd, the window opens first 
time, but we get a prompt to download "mozilla.application/cached-xul" mime-
type subsequently.  

Disabling the XUL cache, loading chrome from the file system, or fixing the 
broken link makes the problem go away.

Reading around in the newsgroups it appears the problem indicates a corruption 
in the xul cache. 

Perhaps this highlights a bug with the xul cache - trying to cache a xul file 
from a jar file with broken links?  It ought to handle xul in a jar file with 
broken links the same way it does on the filesystem - the two should be 

Comment 62

12 years ago
if you no longer see this, but did, please comment so the bug can be closed out.

likewise, if you still see this, please comment. :)

Assignee: hewitt → nobody
QA Contact: jrgmorrison → xptoolkit.xul

Comment 63

12 years ago
It is OK with SeaMonkey 1.1b1
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME


10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.