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)

Product:
Core
Component:
XUL
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jamesrome, Unassigned)

References

Details

(Keywords: regression)

Attachments

(3 files)

screenshot
65.78 KB, image/png
Details
bad chrome.rdf
21.65 KB, text/plain
Details
good chrome
21.64 KB, text/plain
Details
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).
wfm with win2k build 20020222
I rebooted, and that behaviour disappeared! Most wierd.
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?
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla0.9.9, regression
cc'ing Hyatt
Attached image screenshot —
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)
QA Contact: sheelar → esther
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.
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.
this is a smoketest blocker.
Keywords: smoketest
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!
Blocks: 127533
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??]
sending to XUL
Assignee: ducarroz → hyatt
Component: Composition → XP Toolkit/Widgets: XUL
Product: MailNews → Browser
QA Contact: esther → jrgm
This happened sometime between 02/19/2002 06:00:00 and 02/20/2002 06:00:00
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?
Attached file bad chrome.rdf —
Attached file good chrome —
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?
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.
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.
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.
*** Bug 128052 has been marked as a duplicate of this bug. ***
bug 126113 (smoketest blocker, too) seems be a chome.rdf-related issue - is it somehow related to this bug ?
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
Is this happening to everyone using today's verification builds of Mozilla (not Little Mozilla, whatever that is), with either Classic or Modern themes?
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
Adding JFD, to cc list.
Blocks: 128308
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?
Hyatt is listed as giving a presentation at all hands meeting today. I can't get ahold of him or hewitt.
*** Bug 128308 has been marked as a duplicate of this bug. ***
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.
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.
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.
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?
--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
I do not see this in modern skin either. Since there is a workaround reducing the severity.
Severity: blocker → critical
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. ***
*** Bug 129380 has been marked as a duplicate of this bug. ***
Ugh. Never mind. I was using Orbit which looks almost exactly like Modern. Yeah. It's third party only.
*** 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
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]
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!
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. /be
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. ***
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. ;-)
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [need info]
*** Bug 130608 has been marked as a duplicate of this bug. ***
*** Bug 130391 has been marked as a duplicate of this bug. ***
*** Bug 131552 has been marked as a duplicate of this bug. ***
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
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.
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
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.

Attachment

General

Creator:
Created:
Updated:
Size: