Closed Bug 206029 Opened 21 years ago Closed 20 years ago

Flash Plugin installer removes line endings from all.js


(Firefox Build System :: General, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: jack_comics, Assigned: bryner)



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


(2 files, 1 obsolete file)

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, 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
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 
I had this problem, and then installed with the installer from this webpage 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. ***
Changing summary.

This issue will occur when I follow the steps:

It doesn't happen when I follow djst one:

Do you have any ideas?
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

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".

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
So who fixed this and didn't mention? Thanks to those who work quietly in the dark.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030518 Mozilla
*** 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 
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
>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
Closed: 20 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.

*** 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.

"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."

-> Reopen
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
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
There has been at least one official trunk build and one official branch build
over the last few days (links on  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 3.412, you
removed it in 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

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
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
*** 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
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!
Closed: 20 years ago20 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.