Closed Bug 479534 Opened 16 years ago Closed 14 years ago

Firefox 3.06 Wiki On A Stick (Sourceforge) fails to embed new image ActiveXObject error

Categories

(Firefox :: File Handling, defect)

x86
Windows 2000
defect
Not set
minor

Tracking

()

RESOLVED WONTFIX

People

(Reporter: rw-gomersall, Unassigned)

Details

(Whiteboard: [CLOSEME 2010-11-15])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20 Been using Wiki On A Stick (http://stickwiki.sourceforge.net) for a long time in Firefox. All parts work after updating to 3.06 except embedding a new image which fails with an "ActiveXObject is not defined". Reproducible: Always Steps to Reproduce: 1. Load Wiki On A Stick (version 0.9.6b; 0.9.7b)and set up a wiki link in an existing page to trigger image embedding "[[Include::Image::mynewpicture.gif]]". Click this link and the wiki prompts you to "Browse" for the image file, choose one and click "Embed" 2. Occurs every time in every OS I have access to (Win2000, XP, Vista, Ubuntu Hardy, Intrepid) 3. Actual Results: Debug console: [Exception..."Component returned failure code 0x80520001 (NS_ERROR_FILE_UNRECOGNISED_PATH) [nsILocalFile.initWithPATH]" nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNISED_PATH)" location: "JS frame :: file:///xxxxx/xxxx/woas-0.9.6b.htm :: mozillaLoadFile :: line 1793" data: no] Exception while attempting to load ReferenceError: ActiveXObject is not defined Expected Results: I'm not sure how "the magic happens" but the java file should embed the image data into its own self-contained database. I think you get (and have always got) a similar error when using Internet Explorer; though it often won't load the main file at all anyway. I don't embed that many images in my wiki notebooks so this bug may also be in slightly earlier versions. But it certainly worked flawlessly in the initial release and all versions of Firefox 2. The wiki file itself is not corrupt because my current workaround is fine - which is to use portable Firefox 2 from PortableApps.com in parallel just to perform this function). Oh, if you get this far, thanks for taking a look. Cheers.
File Uploading changed between FF2 and FF32 because you can't get the whole file path with Javascript anymore with FF3 (privacy reasons). FF2 returned c:\test\test.gif and FF3 returnes "test.gif". This looks like exactly this issue which would be invalid. What is the javascript doing in the wiki for image uploads ? Did you asked in their support Forums ?
That was quick! The inability to import a path+filename certainly fits with the console errors. Right, this is what should happen: In Firefox 2, once the link has been set up and clicked, the image embedding screen is shown, along with the console message: Retrieving embedded source Image::test01.gif Transcluding Special::Embed(Special::Embed,image) load_as_current("Image::test01.gif") - 187 bytes I then select the image file and click "embed". This doesn't produce a console output, however, merely pauses while it locates/uploads the file and incorporates the image (which doesn't need to be "test.gif" or even a GIF, it's just a tag). So I guess if the path to the file is not transferred along with the filename itself, then you get the error. Maybe having the image file in the same directory as the wiki.htm file would circumvent it. The bug is mentioned in the WOAS forum but hasn't got as far as you have already: http://sourceforge.net/tracker/index.php?func=detail&aid=2049465&group_id=155218&atid=794925
I'm not great with javascript but the wiki.htm file contains these lines which may make more sense to you: woas["_get_embedded"] = function(cr, etype) { log("Retrieving embedded source "+cr); // log:1 var pi=this.page_index(cr); if (pi==-1) { return this.parser.parse("[[Include::Special::Embed|"+etype+"]]"); } return this._get__embedded(cr, pi, etype); The etype is then determined later on: woas["_embed_process"] = function(etype) { var filename = $("filename_").value; if(filename == "") { alert("A file must be selected"); return false; } _force_binary = true; var ct = loadFile(filename); _force_binary = false; if (ct == null || !ct.length) { alert("Could not load file "+filename); return false; } ct = encode64(ct); // calculate the flags for the embedded file if (etype == "image") { var m=filename.match(/\.(\w+)$/); if (m==null) m = ""; else m=m[1].toLowerCase(); var guess_mime = "image"; switch (m) { case "png": guess_mime = "image/png"; break; case "gif": guess_mime = "image/gif"; break; case "jpg": case "jpeg": guess_mime = "image/jpeg"; break; } ct = "data:"+guess_mime+";base64,"+ct; etype = 12; } else etype = 4; pages.push(ct); page_attrs.push(etype); page_titles.push(current); // save everything this.save_to_file(true); this.refresh_menu_area(); this.set_current(current, true); return true;
This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO. Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME. This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.
Whiteboard: [CLOSEME 2010-11-15]
Since it's a fundamental change in the the way firefox 3 interacts with the java requests in WOAS, the workaround is still to use FF2 portably (doesn't affect an installed v3+) offline. So I'll mark it as resolved.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.