Unusual Firefox HTML -URL bug after UURollup
Posted 24 January 2013 - 02:43 PM
Last week I upgraded two machines running W2K SP5.0 with UURollup-v10d. Prior to installing the UURollup, the Image File Execution reg patch was applied and a copy of uxtheme.dll added to the Firefox program directory from BlackWingCat's_KDW-fcwin2k package as per the Firefox 13+ in Windows 2000 instructions posted on Mozillazine (http://forums.mozill...p?f=7&t=2482475).
UURollup installed without a hitch and after a short test drive, Firefox 12 and its crippled Clingon cousins, Java and Adobe flash were uninstalled. After taking a deep breath, I downloaded Firefox 18 which installed perfectly, reserving the final acid test for the Clingon's. I was able to find the pair on BWC's website and downloaded the most current patched versions of Java and Adobe flash. After recently learning these patches were no longer unnecessary, my second machine was updated normally to Firefox 19.x with the most current versions of Flash and Java! These installations went flawlessly, providing a major upgrade that would make Bill Gates blush.
I wanted to express my gratitude to the members of MSFN, particularly BlackWingCat, tomasz86, and others who contributed to this remarkable achievement. I use several operating systems but have always loved Windows 2000 the most. The loss of Firefox support and frequent "XP only" executable's have been about as welcome as a series of automatic transmission failures in the Bronx. Thanks for bringing a little sunshine to the winter of 2013.
Now to address the current problem:
When double clicking on an HTML file, Windows immediately throws an error box in the launching directory "Cannot find the file "X:\yadayada.html" (or one of its components). Make sure the path and filename are correct and that all required libraries are available" This of course is BS since Firefox has already launched the html file in the browser. Unfortunately, each one of these must be cleared by hitting ok, otherwise the blinking warnings accumulate in the taskbar. Oddly, this error can be avoided by the equivalent context menu action, Right-Click-Open-Open with-Firefox.
My immediate hunch was to suspect a file association problem which could not be resolved using the conventional bag of tricks. This brought back unpleasant memories of 2004-06, when Firefox experienced a series of similar bugs associated with "who's boss, Firefox or Internet Explorer?" This began with URL hyperlinks, later mutating to include html documents. The culprit of the Firefox bug involved Microsoft's method of handling outside competition, a convoluted process called ddeexec to control file associations and their dependencies.
As suspected, clicking a URL hyperlink, reproduced nearly identical errors, except that file http://www.yadayada.com listed instead. I spent the last two nights trying to force the OS to recognize the default browser, deleting Firefox's registry associations and rebuilding the stack several times. Although URL associations have been fixed, I've had no luck with changing html behavior.
Is anyone else having problems like this?
Did I do something wrong during installation, or is this a dll dependency like Shell32?
Posted 27 January 2013 - 10:49 PM
W2K SP5.0 is just an arbitrary name for my post SP4 version of Windows 2000. After upgrading for years, In May 2010 I decided to do a fresh install using nLite to slipstream my W2K SP3 disk with SP4, MS Rollup v2, recent hotfixes, and a variety of ad ons based on a detailed MSFN posting, hence SP5.
Other than a few glitches after the initial installation, this OS has been running rock solid on both my machines.
This is an unusual problem that has me really puzzled. Both machines exhibit the same problem so I'm certainly willing to experiment. Not sure if the next move should be another FF install, a downgrade, a different UURollup, play with the Application Compatibility Launcher, etc.
Any suggestions would be appreciated.
Posted 28 January 2013 - 02:33 AM
Cheers and Regards
Posted 28 January 2013 - 12:18 PM
In the meantime I've been looking into several Firefox registry values which determine default browser behavior.
They may or may not have been skewed which could be the source of my errors.
Does anyone know if Firefox is still using the values in bold under either of these keys:
with either "-osint -url" or "-requestPending -osint -url" inserted after the path
"D:\W2Program Files\Mozilla Firefox\firefox.exe" -osint -url "%1"
"D:\W2Program Files\Mozilla Firefox\firefox.exe" -requestPending -osint -url "%1"
And also, any ddeexec keys or subkeys.
Posted 28 January 2013 - 08:50 PM
Here's the latest.
I just clicked a shortcut (Firefox icon) to an html document located on another partition. Windows explorer threw the same error popup, "Cannot find the file 'K:\Web_Docs_Business\A&E_Project.html' (or one of its components). Make sure the path and filename are correct and that all required libraries are available"
This time however, Internet Explorer which I almost never use, launched a browser in a second window returning a different error, complaining that it couldn't find my document in the Bing search engine. IE had munged the document name into a short file name with a .htm suffix.
I took snapshots of both errors and confirmed an hour ago my registry values for Firefox file associations were identical to those in XP. I certainly never had these problems before but still don't have a single suggestion on what to do next. Fortunately it's only a minor headache so I'll let it rest for a while.
Posted 30 January 2013 - 09:35 AM
I had to install Win2K on a school PC (Core 2 Duo, 2GB RAM) and I slipped in UURollup, however, I used an older version of Firefox. (10.05)
I'll have to check URLs on it.
This post has been edited by AnX: 30 January 2013 - 09:35 AM
Posted 30 January 2013 - 03:52 PM
BTW, BUG SOLVED!!
Just figured this out an hour ago and I'm tickled pink. The cause of the problem was a bug in DDE shell integration and the ddeexec registry keys I mentioned in the previous post. DDE is a miserable attempt to shift control of various File Handlers (.htm, .html, .shtml, .xht, .xhtml) and Protocol Handlers (ftp, http, https) depending on the default browser (IE or Firefox) and various file associations. When Firefox dropped their support of Windows 2000, the software developers had an opportunity to remove some of the dysfunctional DDE dependencies without wrecking the browser for W2K users.
UUrollup liberates W2K users to do some very cool stuff, and one of those benefits was upgrading to FF18. For many users, DDE perpetually coexists in a semi-corrupt state without ever being noticed. Unfortunately, after my FF 18 upgrade it became problematic once again. This issue has been a continual headache for Firefox developers since 2004 and after reading the following bug report I found a solution which worked.( https://bugzilla.moz...g.cgi?id=491947 )
The fix involved using a script to delete a number of FF related registry keys and another to rebuild the configuration.If anyone is interested I'll post the specifics.