Closed
Bug 127322
Opened 23 years ago
Closed 18 years ago
compose window does not load (prompts for download) [XUL cache??]
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jamesrome, Unassigned)
References
Details
(Keywords: regression)
Attachments
(3 files)
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
mail.
Why has this changed suddenly (in the p[ast week).
Comment 1•23 years ago
|
||
wfm with win2k build 20020222
Reporter | ||
Comment 2•23 years ago
|
||
I rebooted, and that behaviour disappeared! Most wierd.
Reporter | ||
Comment 3•23 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?
Reporter | ||
Comment 4•23 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?
Comment 5•23 years ago
|
||
Something went wrong with the installation apparently! All those XUL files are
part of JAR file. Try doing a clean install.
Reporter | ||
Comment 6•23 years ago
|
||
I uninstalled, deleted the mozilla directory, reinstalled, and the same thing
happens.
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!
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.
Comment 8•23 years ago
|
||
cc'ing Hyatt
Comment 10•23 years ago
|
||
changing summary from:
Can no longer compose mail
to:
compose window does not load (prompts for download)
Summary: Can no longer compose mail → compose window does not load (prompts for download)
Comment 11•23 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•23 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.
Reporter | ||
Comment 14•23 years ago
|
||
This is a regression, since it all worked before. I was wondering if my bug
about saving .exe files http://bugzilla.mozilla.org/show_bug.cgi?id=116938
had a fix put in that changed this!
Comment 15•23 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.
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•23 years ago
|
||
sending to XUL
Assignee: ducarroz → hyatt
Component: Composition → XP Toolkit/Widgets: XUL
Product: MailNews → Browser
QA Contact: esther → jrgm
Comment 17•23 years ago
|
||
This happened sometime between 02/19/2002 06:00:00 and 02/20/2002 06:00:00
Comment 18•23 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?
Comment 19•23 years ago
|
||
vadim, yes, please attach those chrome.rdf files.
is this still a smoketest blocker?
Comment 20•23 years ago
|
||
Comment 21•23 years ago
|
||
Comment 22•23 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•23 years ago
|
||
Pratik,
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•23 years ago
|
||
Vadim,
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.
Reporter | ||
Comment 25•23 years ago
|
||
Well, using the classic theme, things seem to work. But when I switch back to
the 0.98 LittleMozilla, it dies again.
Comment 26•23 years ago
|
||
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•23 years ago
|
||
*** Bug 128052 has been marked as a duplicate of this bug. ***
Comment 28•23 years ago
|
||
bug 126113 (smoketest blocker, too) seems be a chome.rdf-related issue - is it
somehow related to this bug ?
Comment 29•23 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•23 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•23 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•23 years ago
|
||
Adding JFD, to cc list.
Comment 33•23 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
code?
Comment 34•23 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•23 years ago
|
||
*** Bug 128308 has been marked as a duplicate of this bug. ***
Comment 36•23 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•23 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:
http://lxr.mozilla.org/seamonkey/source/editor/ui/composer/content/contents.rdf#16
Skins built to work on moz 0.9.4 will definitely break on current builds. But
perhaps this isnt the real issue.
Comment 38•23 years ago
|
||
Peter,
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•23 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?
Comment 40•23 years ago
|
||
why is this holding the tree closed if it's only 3rd party skins?
Comment 41•23 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•23 years ago
|
||
I do not see this in modern skin either.
Since there is a workaround reducing the severity.
Severity: blocker → critical
Comment 43•23 years ago
|
||
I was seeing this on Modern, but I had other themes installed.
So it's not only 3rd party.
Comment 44•23 years ago
|
||
*** Bug 128445 has been marked as a duplicate of this bug. ***
Comment 45•23 years ago
|
||
*** Bug 129380 has been marked as a duplicate of this bug. ***
Comment 46•23 years ago
|
||
Ugh. Never mind. I was using Orbit which looks almost exactly like Modern.
Yeah. It's third party only.
Comment 47•23 years ago
|
||
*** Bug 128781 has been marked as a duplicate of this bug. ***
Comment 48•23 years ago
|
||
*** Bug 127533 has been marked as a duplicate of this bug. ***
Comment 49•23 years ago
|
||
nominating, since this breaks third-party themes
Blocks: 127533
Keywords: mozilla1.0,
nsbeta1
Comment 50•23 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]
Reporter | ||
Comment 51•23 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•23 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?
Comment 53•23 years ago
|
||
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.
/be
Comment 54•23 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?
Comment 55•23 years ago
|
||
*** Bug 130335 has been marked as a duplicate of this bug. ***
Comment 56•23 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 mozilla.org 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. ;-)
Comment 57•23 years ago
|
||
*** Bug 130608 has been marked as a duplicate of this bug. ***
Comment 58•23 years ago
|
||
*** Bug 130391 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
*** Bug 131552 has been marked as a duplicate of this bug. ***
Comment 60•22 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•22 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
consistent.
Comment 62•18 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. :)
WFM
Assignee: hewitt → nobody
QA Contact: jrgmorrison → xptoolkit.xul
Reporter | ||
Comment 63•18 years ago
|
||
It is OK with SeaMonkey 1.1b1
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
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.
Description
•