Closed Bug 206029 Opened 22 years ago Closed 21 years ago

Flash Plugin installer removes line endings from all.js

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Firefox0.9

People

(Reporter: jack_comics, Assigned: bryner)

References

Details

(Keywords: regression, Whiteboard: [Flash Player installer issue])

Attachments

(2 files, 1 obsolete file)

screenshot
14.32 KB, image/png
Details
use preprocess --line-endings
1.62 KB, patch
bryner
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 If I use Seb's Firebird Web Installer that creates registry entries for Mozilla Firebird, or if I use the registry file provided by http://plugindoc.mozdev.org/phoenix.html, initially Firebird works fine. However, if and when I install the latest version of Macromedia Flash 6 which recognizes Mozilla Firebird, I'll re-open Mozilla Firebird, only to have some very strange effects. The most obvious changes are that Mozilla Firebird is now using the "Classic theme," and there are extra toolbars... Help, and QA. Also, if you try doing anything, absolutely nothing works. So, to sum it all up, installing Flash with Mozilla Firebird using the proper registry keys makes Mozilla Firebird completely and utterly useless. Reproducible: Always Steps to Reproduce: 1. Use the registry file provided by http://plugindoc.mozdev.org/phoenix.html 2. Use the latest Macromedia Flash installer to install Firebird Flash plug-in. Actual Results: Mozilla Firebird becomes utterly useless each and every time opened after completing the above steps, switched to "Classic" theme, and has extra toolbars such as QA and Help. Expected Results: Mozilla Firebird should have had Flash correctly installed, and loaded up as normal.
I had this problem, and then installed with the installer from this webpage http://downloads.mozdev.org/seb/MozillaFirebird-0.6-setup.exe and reinstalled flash. It works perfectly, so you should email whoever made the great installer to see what they changed.
Summary: Creating Good Flash Registry Entry and Installing Flash Makes Mozilla Firebird Unusable → Installing Flash changes Firebird UI into Mozilla one
*** Bug 206033 has been marked as a duplicate of this bug. ***
*** Bug 206040 has been marked as a duplicate of this bug. ***
Confirming... Changing summary. Hendikins: This issue will occur when I follow the steps: http://plugindoc.mozdev.org/faqs/phoenixwin.html http://plugindoc.mozdev.org/resources/firebird.reg It doesn't happen when I follow djst one: http://texturizer.net/firebird/faq.html#2.1 Do you have any ideas?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Installing Flash changes Firebird UI into Mozilla one → Firebird UI changes into Mozilla one after Installing Flash
After testing this on Win2k, I've found that the Flash Player installer removes the line endings from \defaults\pref\all.js when modifying it, which in turn causes this unwanted behaviour. This only happens when the Flash Player installer locates the browser using the registry. If the Plugins directory is manually selected, the installer does not modify all.js or install scripting support - which is why this behaviour does not happen when a. the registry entries are not present or b. the detected browser is deselected, and it's plugins directory manually selected. Workaround is to back up \defaults\pref\all.js before installing the Flash Player, then replace it with the original version after installing Flash Player. Reducing severity to major, since this doesn't case a crash/dataloss.
Severity: critical → major
Summary: Firebird UI changes into Mozilla one after Installing Flash → Flash Plugin installer removes line endings from all.js
Whiteboard: [Flash Player installer issue]
Seb's great web installer use it's application name (for registry) as "Firebird" instead of "Mozilla Firebird". Hendy: Can you check his build also being able to install scripting support?
I can reproduce this on WinXP. Haven't ever screwed up Firebird like this! Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
So who fixed this and didn't mention? Thanks to those who work quietly in the dark. WFM. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030518 Mozilla Firebird/0.6
*** Bug 206224 has been marked as a duplicate of this bug. ***
I just tried something: I converted \default\pref\all.js from UNIX (only LF for new lines) to DOS format (CR+LF for new lines). Result: Flash installs perfectly, and all.js is still in normal (but DOS) format. So (imho): either the flash installer is faulty, or all.js should be in dos format.
*** Bug 206336 has been marked as a duplicate of this bug. ***
Another work-around, if you have plug-ins installed for Mozilla, is to copy the desired plug-ins from Mozilla's "Plugins" directory into Mozilla Firebird's.
I can now reproduce this bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030519 Mozilla Firebird/0.6. This is what I did: 1. Rename the MozillaFirebird directory to something different in order to have a backup. 1. Copy the nightly into a newly created MozillaFirebird directory, which is the one set in the registry. 2. Install flash. The bug occured. I repeated 1-3 with 05/18 (and 0.6). The bug also occured. I cannot explain this as 05/18 seemed to work for me. But now it doesn't. Using a new profile changes nothing. Maybe the reason is something outside the program directory, e.g. the registry.
*** Bug 206548 has been marked as a duplicate of this bug. ***
To Steffan (#13): I think Anton (#10) answers your question. The all.js file that apparently gets damaged by the Flash installation is not found in the profile. It's in a subdirectory a couple of layers under the executable.
*** Bug 208151 has been marked as a duplicate of this bug. ***
Why uses M. Firebird (for Windows) an all.js with UNIX format if Mozilla (for Windows) uses PC/DOS format? IMO this is the fault. So the answer for the question from comment 10 is to use the PC/DOS format for all pref files as Mozilla (for Win) always does it.
*** Bug 208350 has been marked as a duplicate of this bug. ***
Can anybody still reproduce? WFM here.
I can reproduce this bug with the latest official win32 build from 7/6, running XP. WFM using Aebrahim's 7/9 build: \default\pref\*.js have DOS line feeds. But I think this is specific to Aebrahim's builds. The files in his 5/29 build also have DOS line feeds. But the official builds since then don't. The solution to fix this is to use DOS line feeds therefore like Mozilla does. See comment 17.
Has anybody reported this to Macromedia? If I do not get a reply with a day or two, I will report it to them.
Umm, there's no real reason to report this bug to Macromedia, as it's not a Macromedia Flash bug. It's a Mozilla Firebird bug. For some unknown reason, the Mozilla Firebird pref files use UNIX line feeds, which it shouldn't. Mozilla SeaMonkey correctly uses PC/DOS line feeds for its pref files, which is what Mozilla Firebird should do as well, but it doesn't. Switching Mozilla Firebird's pref files to use PC/DOS line feeds would correct this bug.
Attached image screenshot —
Mozilla Firebird 0.6.1 release for Win uses still the UNIX line feeds for the default prefs. :-(
I'm going to take a crack at fixing this by telling cygwin on the primary Firebird build machine to not use unix line endings. This is still a problem that would be nice to see fixed on the Macromedia side since we don't control the machines used to make every available firebird build and many developers will opt for unix line endings. Ideally Macromedia wouldn't be writing to our all.js at all. They should write out to their own file, a flash.js or something like that. If they are going to write to our all.js then they should check the line endings and not mangle the file.
>This is still a problem that would be nice to see fixed on the Macromedia side I must agree with this, because problem with DOS <-> Unix Enters is in Mozilla so unusual that some days ago we discovered, that we have this problem in every Czech localized version of the Mozilla! So not only FireBird have to have this problem, but also localizers can make it (because nobody knows about bug #206029).
I read a comment that the .exe unofficial build works, and that is good news. However, it needs to be fixed in ALL versions as soon as possible. Especially now that the Mozilla site is advertising Firebird, it will reflect badly if this problem exists in the official 0.6.1. In my opinion the severity should be raised to a blocker, and no further official versions should be released until this problem is done away with. I say this as a well-wisher and an avid user of Firebird. Flash is a fairly common plugin to have, so please fix this with utmost urgency.
Target Milestone: --- → Firebird0.7
We could make the build system change the line endings to DOS when the files are installed into dist/bin. That would make it "more or less" foolproof.
This patch makes files installed via PREF_JS_EXPORTS get DOS line endings on platforms that use those line endings. (I'm also removing a stray tab that emacs complains about)
Attachment #129531 - Flags: review?(cls)
Comment on attachment 129531 [details] [diff] [review] fix up line endings for pref .js files That's nasty. I agree with Asa; Macromedia should fix their installer to not touch existing files unnecessarily. Use $(PERL) instead of perl && r=cls
Attachment #129531 - Flags: review?(cls) → review+
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment on attachment 129531 [details] [diff] [review] fix up line endings for pref .js files Post-checkin approval, this is ok for 1.5b. /be
*** Bug 214327 has been marked as a duplicate of this bug. ***
*** Bug 220792 has been marked as a duplicate of this bug. ***
Bug seems to have returned in trunk builds after 20040101.
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20040102 Firebird/0.7+ the bug doesn't appear. So, I would say it's now confined to only the newer trunk builds.
bug returned approx. 10 days ago for me.
http://forums.mozillazine.org/viewtopic.php?p=321644#321644: "aebrahim: the last 2 builds from you I tried, 01-01-2004 and this one, had a unix-style \mozillafirebird\defaults\pref\all.js file. Remember bug 206029? Flash installer breaks firebird because of this. I recall using earlier builds from you that had dos-style .js files, the way they should be on Windows."
Indeed. -> Reopen
Status: RESOLVED → REOPENED
Keywords: regression
Resolution: FIXED → ---
This problem can be easily fixed by changing build machine setting. Set "Default Text File Type" on Cygwin Installer not Unix but DOS.
Assignee: blake → bryner
Status: REOPENED → NEW
Component: General → build-config
Target Milestone: Firebird0.7 → Firebird0.9
has anyone else built from trunk recently to test this? could it be just a build environment with aebrahim and not an issue with a standard build environment?
Now it seems the problem has migrated into the pre-0.8 branch builds. See http://forums.mozillazine.org/viewtopic.php?t=45607
There has been at least one official trunk build and one official branch build over the last few days (links on http://www.squarefree.com/burningedge/). Does this bug appear in those builds?
This is still a problem with the flash player installer (tested with 7.0 r14). It wants to add "application/x-shockwave-flash" to the pref "network.http.accept.default" in bin/defaults/pref/all.js. It messes up all.js if that has got unix-style line endings. (If you want to test this, make a backup of all.js, but don't call it e.g. "copy of all.js", because Firebird ready any *.js file. Rename the copy to e.g. "all.js.bak".) On the branch (official installer Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040114 Firebird/0.7+), all.js still has windows-style line endings, so there's no problem. On the trunk, we've renamed bin/defaults/pref/all.js to firebird.js, and removed "network.http.accept.default" yesterday, because that's now part of bin/greprefs/all.js, see bug 224578 and bug 231200. So it doesn't matter that both files have unix-style line endings, because the flash player installer can't find any of them. Flash works fine without modifying that pref AFAICT. I'd mark this fixed if nobody disagrees. I don't know why we're back to unix-style line endings. CCing bsmedberg.
does it install without errors? the accept header will make a difference on some servers and I'm sure that Macromedia will change this to check the new location once they catch on. We should look at making sure the *.js files have windows-style line endings on win32 as a future-proof solution against this regressing in the future (unless someone can convince Macromedia to handle the file better).
I tested with 2004-01-15-15-trunk and it works for me. (all.js has CR+LF Windows style line ends.) I don't know who fixed the setting. So marking as WFM?
the relevant checkins were after the 15th, so that's not relevant
bsmedberg: you removed bryner's patch from comment 29 which "makes files installed via PREF_JS_EXPORTS get DOS line endings on platforms that use those line endings". It's the "s/([^\r]?)\n/\1\r\n/" thing. Bryner added it to rules.mk 3.412, you removed it in 3.424: http://bonsai.mozilla.org/cvsview2.cgi?file=rules.mk&subdir=mozilla/config&command=DIFF_FRAMESET&rev1=3.423&rev2=3.424 The problem is that the files in my tree are windows style, but the preprocessor converts them to unix style. Of course it's mainly Macromedia's fault. They should simply add a flash.js instead of runining our files (already suggested in comment 25).
I'm confused. Do I need pref files to have DOS line endings now or not? bin/defaults/pref/all.js doesn't exist anymore, in seamonkey or firebird.
If needed.
Attachment #129531 - Attachment is obsolete: true
We need the DOS style line endings because Macromedia will probably just take whatever the new file is called and break that trying to append to it when they discover that all.js doesn't exist anymore. Besides, its just a good practice to use DOS line endings on Windows platforms.
Comment on attachment 139605 [details] [diff] [review] use preprocess --line-endings Works fine! Bryner, r?
Attachment #139605 - Attachment description: use preprocess --line-endings (is this needed)? → use preprocess --line-endings
Attachment #139605 - Flags: review?(bryner)
RE comment 38 and comment 41: Yes, it was a problem with my build environment. I had Cygwin set to UNIX style line endings instead of DOS style, and this caused the problem. This is now fixed and subsequent builds of mine (if any) should have the correct DOS style line endings.
I hit this bug from the 0.8 branch build linked from Asa's blog http://ftp.mozilla.org/pub/mozilla.org/firebird/nightly/2004-02-07-04-0.8/ It would be nice if somebody could test and verify if Ben's "Grandma killing bugs" 0.8 builds don't have this bug
Testing with http://ftp.mozilla.org/pub/mozilla.org/firebird/nightly/2004-02-08-04-0.8/FirebirdSetup.exe Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040208 Firebird/0.7+ I don't know how and when this happened, but all.js is back to unix style line endings on the branch, thus showing this nasty bug. This is a "Grandma killing bug" IMHO! For 0.8, someone just needs to convert all.js to dos style line endings.
Setting blocking0.8? since we probably don't want to ship with this.
Flags: blocking0.8?
Firefox 0.8 shipped with the correct dos style line endings, i.e. it's not affected by this bug. We still should get the patch into the trunk, see comment 51.
Flags: blocking0.8?
Comment on attachment 139605 [details] [diff] [review] use preprocess --line-endings My only concern with this would be if you're building with cygwin configured for DOS line endings, will this give you duplicate line endings?
> My only concern with this would be if you're building with cygwin configured > for DOS line endings, I do that. And I know that for sure, because jEdit displays the type of the line endings. My files are all dos style. will this give you duplicate line endings? Nope. The exported pref files, e.g. dist/bin/defaults/pref/firebird.js and dist/bin/greprefs/all.js all get ordinary, well behaved, single dos style line endings. Without this patch, they are unix style.
The official win32-build of 2004-02-21 has the correct dos-style line endings in all.js. Actually, all .js files have them now. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040221 Firefox/0.8.0+
*** Bug 235192 has been marked as a duplicate of this bug. ***
Attachment #139605 - Flags: review?(bryner) → review+
Comment on attachment 139605 [details] [diff] [review] use preprocess --line-endings Does this need sr? If not, can somebody check this in please?
IS this still an issue? leaf said that the build machines are using DOS line endings now, so it shouldn't be an issue.
It should be fixed properly for the sake that it would be pretty easy to accidentally switch the build machines back to Unix line endings accidentally. Also, we support both modes in Cygwin, so we should fix this regardless the validity of the first argument: "Note: binmode (unix lineendings) or textmode (dos lineendings) doesn't matter as long as you use an editor (emacs, msdev) which can handle the appropriate line-endings." (from http://www.mozilla.org/build/win32.html)
I'll land this before freeze, if no one gets to it first.
checked in 03/09/2004 16:22
Thanks Mike. It was bsmedberg's patch though, see comment 50. Should be fixed now once and for all!
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: