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

VERIFIED WORKSFORME

Status

()

VERIFIED WORKSFORME
18 years ago
17 years ago

People

(Reporter: jrgmorrison, Assigned: adamlock)

Tracking

Trunk
mozilla0.9
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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').
(Reporter)

Comment 1

18 years ago
Created attachment 21473 [details]
testcase; try to get and then to set document.cookie in JS
(Assignee)

Comment 2

18 years ago
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.
(Reporter)

Comment 3

18 years ago
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
(Reporter)

Comment 4

18 years ago
<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 → ---

Comment 5

18 years ago
Updating QA Contact
QA Contact: jrgm → mdunn
(Assignee)

Comment 6

18 years ago
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?
(Assignee)

Comment 7

18 years ago
Ack, circular reference. This *is* bug 63999. The question is still the same 
though - has this bug been fixed?
(Reporter)

Comment 8

18 years ago
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. 
(Assignee)

Comment 10

18 years ago
Once profile switching goes in this bug should go away. Adding a dependency.
Depends on: 66533
(Assignee)

Updated

18 years ago
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 11

18 years ago
*** Bug 70988 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 12

18 years ago
CC'ing Jud & Chak
(Assignee)

Comment 13

18 years ago
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 ago18 years ago
Resolution: --- → WORKSFORME

Comment 14

18 years ago
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein

Comment 15

18 years ago
reassign qa contact to Dharma.
QA Contact: depstein → dsirnapalli

Comment 16

17 years ago
-- Marking bug as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.