FF Nightly (Metro) Win 8.... and NORTON :(
Stupid partial OS reinstall corrupted on old computer now stuck in perpetual install loop, just ran out bought new laptop w/ Win 8 (no choice)... as former dev, hate IE & ironically installed Nightly w/out even realizing it's the bomb when it comes to (the 'former' Metro, of which I personally find annoying) Honestly, initial Nightly choice due to previous pet peeve re: x64 - sorry guys ;) Anywhoo, here we go again, now w/ the same 'ol NORTON issue.... what's a girl to do? I illogically thought that maybe the last Norton hotfix/ patch for latter FF might've worked... even tried & somewhat hopeful that redefining path to coFFPlgn.dll manually would do something, anything - like show up as a grey-/ gray-ed out ext, plgn, anything... so exactly who's lap is this one supposed to fall in to? I know Norton guys will say their FF patch should've covered it regardless. Personally, I don't care who what where - all I know is that it is something that absolutely needs to work.... actually almost got hit today w/ a nasty nasty embedded in a web page (innocently ;) that fortunately was caught & blocked before ending up w/ another useless oversized paperweight
כל התגובות (3)
AFAIK, Norton doesn't support pre-release software, which would include Beta, Aurora, and all versions of Nightly. Best to ask Norton support to see if they even have a Firefox 64-bit version of their DLL's.
Thanks so much for your reply - I certainly appreciate it :) While I absolutely can understand what you're saying, I just can't help but wonder if/ why this perpetual FF-NIS issue wouldn't be given any consideration right off the bat w/ any newer build.... Knowing that a special 'metro-style' version of FF (aka Nightly) was especially & specifically built from the ground up for the latest (maybe not so greatest) Win 8 (formerly Metro), one might think it would have all bases covered regardless of pre- or post-release... ???
... and yes, there is a x64 FF specific DLL which manually redefining a path to didn't exactly work (then again, thinking about it - FF was looking for a .xpi or .jar) Could the problem possibly be as simple as this?
Norton creates add-ons for Firefox - Norton is adding to Firefox, making Firefox the primary application. Therefore it is up to Norton to make consideration for Firefox. IOW, Norton is the one who is perpetuating this Firefox-Norton "issue".
As far as pre- and post-release goes, some or all of the add-ons that Norton makes for Firefox contain binary components which need to be updated for each new version of Firefox. There is an element of risk involved when working in advance of a Firefox release date, that an add-on developer might have to make repeated updates or changes to their add-on as Firefox moves thru the Nightly and Aurora stages of development; less so for the Beta stage, where changes are usually "fit and finish" rather than core code. So rather than spend development dollars too early in the pre-release stages add-ons developers tend to wait until the last minute to even test their stuff against the Beta version, or even wait until a new version of Firefox is released and their users start complaining about their product being disabled by the new Firefox version.
Overall Norton seems to have been doing a fine job with updating their add-ons in a timely manner, usually having their updated stuff available like two hours after Mozilla turns on the update servers on the release date. Norton did "slip up" a bit with Firefox 22, it seems that their Vulnerability Protection add-on for Firefox wasn't available for a few days after the release date, causing consternation for some users who received their Firefox 22 update in the first few days of the most recent update cycle.