63999 - winEmbed does not implement 'document.cookie' JS/DOM Level 0

Status: VERIFIED WORKSFORME

(Core Graveyard :: Embedding: APIs, defect)

Description

[John Morrison]

using the winEmbed build: 
 ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-12-29-21-Mtrunk/embed-win32.zip

If you get the document.cookie property, the value is returned as undefined.

If you attempt to set the document.cookie property, a JS exception is thrown:

JavaScript error:
 line 0: uncaught exception: [Exception... "Factory not registered"
 code: "-2147221164" nsresult: "0x80040154 NS_ERROR_FACTORY_NOT_REGISTERED)"
 location: "file:///c|/temp/foo.html Line: 10"]

I assume that this is just work not yet done (particularly given the telltale
'factory not registered').

Comment 1

[John Morrison]

Attachment: testcase; try to get and then to set document.cookie in JS

Comment 2

[Adam Lock]

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.

Comment 3

[John Morrison]

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).

Comment 4

[John Morrison]

<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).

Comment 5

[Paul Wyskoczka]

Updating QA Contact

Comment 6

[Adam Lock]

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?

Comment 7

[Adam Lock]

Ack, circular reference. This *is* bug 63999. The question is still the same 
though - has this bug been fixed?

Comment 8

[John Morrison]

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.

Comment 9

[Conrad Carlen (not reading bugmail)]

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. 

Comment 10

[Adam Lock]

Once profile switching goes in this bug should go away. Adding a dependency.

Comment 11

[Adam Lock]

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

Comment 12

[Adam Lock]

CC'ing Jud & Chak

Comment 13

[Adam Lock]

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.

Comment 14

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 15

[David Epstein]

reassign qa contact to Dharma.

Comment 16

[dsirnapalli]

-- Marking bug as verified.