644 bytes, text/html
Are you sure this test case is correct? I get similar errors if I try and view the attachments with IE (on the Mac) or NS 4.x. The "factory not registered" stuff must be happening on the server side. As far as I can see from stepping the code, the document.cookie property is implemented correctly with the cookie service correctly looking for the cookie and returning it. It could be that because embedding still doesn't use profiles that the cookie is not being saved to file but the property is definitely there and functioning.
Well. Looky that. This has automagically started working in the past week. For today's builds on mac/linux/win32, I don't get this error anymore, and I can retrieve the document.cookie property. (The 'factory not registered' message is a copy of what was showing in the console, and is visible when using Nav4 or IE (since it's just hard-coded ascii in the test case). But the exception was being thrown in the console for real in earlier mozilla builds). So marking WORKSFORME. [Tracy -- can you see if the page loading works with the embedded browser builds? It should work now.] As a side note, though, you said: > It could be that because embedding still doesn't use profiles that the > cookie is not being saved to file but the property is definitely there > and functioning. That raises a question: it occurred to me when you said that, that there will be embedded scenarios where there will be no profile by design (e.g., a simple embedded document viewer as part of some other application). In that case, cookies need to still work without any assumption that a profile will exist. (Although I imagine that this is not something new to you).
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
<smacks forehead/> Well, duh. The winEmbed build, John, the winEmbed build ... Sorry, I checked this in mozilla/seamonkey this afternoon. I don't know where my head was at. This does not work (throws the error) with the build : ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-01-08-06-Mtrunk/embed-win32.zip Note that the error occurs when I attempt to set the property. When I 'get' the property, it does work fine, in the sense of no error, but it shouldn't be undefined (i.e., the property exists and works from a JS perspective, but it is not actually retrieving anything).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updating QA Contact
QA Contact: jrgm → mdunn
CC'ing Conrad to see if profiles (or the lack thereof) has something to do with this problem. Tracy, I notice you don't report bug 63999 any more. Does this mean this bug is fixed too?
Ack, circular reference. This *is* bug 63999. The question is still the same though - has this bug been fixed?
This still happens. I was running with yesterday's winEmbed build (from ftp.mozilla.org), and getting document.cookie returns |undefined|, and setting throws an exception. (The page load tests now work since I changed them to check that .cookie is defined before I use it, and if undefined I use a different way to get the same information that I was looking for in the .cookie). It may well be that the absence of profiles determines this behaviour.
It does. Cookies won't work without profile-relative file locations. Profile Manager is not needed for this though. An easy way around this is to use the MPFileLocProvider lib. gtkEmbed uses this approach. See bug 49223.
Once profile switching goes in this bug should go away. Adding a dependency.
Depends on: 66533
*** Bug 70988 has been marked as a duplicate of this bug. ***
CC'ing Jud & Chak
Marking WORKSFORME cookie.dll is now in the embedding build and profile switching is working in winEmbed. Opening the test attachment shows no JS errors on the console and the code appears to be functioning correctly as in 4.x.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
reassign qa contact to Dharma.
QA Contact: depstein → dsirnapalli
-- Marking bug as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.