If the uninstall.log file has been removed, a pave-over installation of Firefox 4 will not remove all old files and causes the 'I'm feeling lucky" search to fail

RESOLVED INVALID

Status

()

Firefox
Search
RESOLVED INVALID
7 years ago
7 years ago

People

(Reporter: Ben, Unassigned)

Tracking

Trunk
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110311 Firefox/4.0b13pre
Build Identifier: Mozilla Firefox 4.0 RC 1

When i open a new tab and attempt to search for something eg mozilla the URL bar this error comes up

Firefox can't find the file at jar:file:///C:/Program Files/Mozilla Firefox/omni.jar!/chrome/en-US/locale/browser-region/region.propertiesmozilla.

I'm running/have tried..

- adblock plus (tried disabling it, didnt make a difference)
- using default skin
- i dont have the ask toolbar or vuze/azurues
- making a new profile/deleted old profile doesn't make a difference 
- tried uninstall/reinstalling
- deleted old files from appdata, roaming and local mozilla folders
- made new profiles
- i have gone back to minefield 4.0 13pre and it works with the same profile, add-ons etc



Reproducible: Always

Steps to Reproduce:
change a setting in about:config?


Expected Results:  
opened up google with the name i searched for
(Reporter)

Updated

7 years ago
Version: unspecified → Trunk
(Reporter)

Comment 1

7 years ago
i typed some things twice, oops ^_^
(Reporter)

Updated

7 years ago
Severity: major → normal
(Reporter)

Updated

7 years ago
Severity: normal → minor
This is a fresh installation of Firefox? Or have you installed RC1 over an existing older version?
(Reporter)

Comment 3

7 years ago
i had firefox 3.6 or something but then i used minefield for the firefox 4 beta's then i removed minefield and updated to RC1 and it copied over the old version and now the error appears.

it never used to appear when i was using the old firefox or when i was using minefield

atm i have gone back to minefield with no error
(Reporter)

Comment 4

7 years ago
but as i have said i have tried those few things and searching google and the answers didn't work so i think it's a error in RC1
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 479291
(Reporter)

Comment 6

7 years ago
it's not a duplicated since the things i have tried to resolve the issue dont work, hopefully it automatically fixes itself when FF4 is released
>it's not a duplicated since the things i have tried to resolve the issue dont
>work,

Remove all installed addons ?
s31, do you have a global extension called "Ask Toolbar" installed? This extension would also appear in any fresh profile. If that's the case, does disabling it help?
Duplicate of bug: 453288
(Reporter)

Comment 9

7 years ago
@ matthias - i have disablled all add-ons and plugins and restarted RC1 and no difference

@ henrik - i dont have the ask toolbar listed in add-ons, if its listed elsewhere i am not sure?

add-ons installed
- adblock plus

plugins installed
- adobe acrobat reader
- google earth
- google update 
- itunes app director
- 2 x MS office stuff
- mozilla default
- quicktime
- shockwave 
- silverlight
- windows genuine advantage
(Reporter)

Comment 10

7 years ago
ok i have found a fix :D

i checked minefield, in about:config it had nothing next to keyword.url

i checked FF4 RC1, in about:config it had chrome://browser-region/locale/region.properties

when i removed chrome://browser-region/locale/region.properties it now works

is this ok to remove?
(Reporter)

Comment 11

7 years ago
ok i have found a fix :D

i checked minefield, in about:config it had nothing next to keyword.url

i checked FF4 RC1, in about:config it had chrome://browser-region/locale/region.properties

when i removed chrome://browser-region/locale/region.properties it now works

is this ok to remove?
(Reporter)

Comment 12

7 years ago
the value in minefield was set to blank*
Did that happen with the same profile? What's the value when you create a fresh profile with Firefox 4 RC1?
(Reporter)

Comment 14

7 years ago
yep the same new profile i created a few days ago.

when i make a new profile and start firefox the value goes to chrome://browser-region/locale/region.properties

i asked a few others who are using RC1 and there value was blank.

so is chrome://browser-region/locale/region.properties the default?

i think it may have to be removed permanently but im not sure what it's there for as i see the chrome folder in c drive > program files > mozilla firefox > chrome
Ok, so please tell us which locale of Firefox are you using? Looks like it's not the en-Us.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
(Reporter)

Comment 16

7 years ago
i posted this when i was using minefield, im now using Mozilla Firefox 4.0 (x86 en-US) aka Mozilla Firefox 4.0 RC1
So when using en-US and creating a new profile still puts the region.properties URL into the keyword.url preference?
(Reporter)

Comment 18

7 years ago
yep, is it on via default?

what exactly does that chrome folder in c drive do?
the omni.jar file is a zipped archive. If you open it please check default/prefs/firefox.js. That file contains the default value for that preference and should be empty. If you cannot open the archive you can send me the file. Btw. you have downloaded the RC 1 build from our servers?
(Reporter)

Comment 20

7 years ago
i opened it with java, not sure what it exactly means, where can i send/upload the picture or send the file to you?

yep i downloaded it from mozilla's site
Send it to my Bugzilla email address. That's fine.
(Reporter)

Comment 22

7 years ago
ok i have sent the print screen (i couldn't get a good one because it auto closes) and i cant attach the file as a email attachment

can i rar the file or upload it to a hosting site? eg mediafire
I haven't received any email. Please make sure you don't send emails to the bugzilla internal address. If you upload an archive please compress the whole Firefox application folder. So I have everything included. Thanks.
I see this bug too with the Danish da locale version of FF4 RC1.

I tried creating a new profile and keyword.URL is still set to a default of "chrome://browser-region/locale/region.properties"
Deleting the value does indeed fix the problem.

I opened C:\Programmer\Mozilla Firefox\Omni.jar and looked in defaults\prefs\firefox.js and found keyword.URL. The line reads:
pref("keyword.URL", "");
Note that in firefox.js many other values DO have a default value of chrome://browser-region/locale/region.properties including browser.search.defaultenginename :
pref("browser.search.defaultenginename",      "chrome://browser-region/locale/region.properties");

Could this be a clue?
I will check how to reproduce this issue. Christian, is that a regression for you compared to Firefox 3.6? Did older beta releases work?
Severity: minor → normal
Summary: getting errors when attempting to search in the URL bar → Search in location bar fails and throws an error
Christian, can you please open this chrome URL for region.properties and check the value for 'browser.search.defaultenginename'? What does it contain? I don't see the problem with RC1 (da) on Windows 7. Which platform are you testing on?
Can both of you please run Firefox in Safe Mode (http://support.mozilla.com/en-US/kb/Safe%20Mode) to ensure that this problem does not exist when all add-ons have been disabled? Thanks.
(Reporter)

Comment 29

7 years ago
@ henrik - i sent the email to hskupin@gmail.com, is this the correct one?

i have run firefox in safe mode, disabled all add-ons and reset preferences and it's still the same

henrik if you type in about:config and type keyword.url does yours have the chrome://... etc or no value?
(In reply to comment #29)
> @ henrik - i sent the email to hskupin@gmail.com, is this the correct one?

No, I haven't gotten any mail. It's even not located inside the spam folder. So if you have a change to upload it somewhere I would appreciate it.

> henrik if you type in about:config and type keyword.url does yours have the
> chrome://... etc or no value?

No, it's always empty. Can you btw. try the same with another Windows user account? Is that reproducible then?
(Reporter)

Comment 31

7 years ago
can i upload the file to eg mediafire so you can download? is this host ok for you?

i will try a new account and reply shortly
(Reporter)

Comment 32

7 years ago
i opened a new windows user account and all my programs were still on there lol
(Reporter)

Comment 33

7 years ago
what if i try RC1 on laptop to see if its reproducible?
(Reporter)

Comment 34

7 years ago
i made another new account in firefox to check something and now the only thing in default/prefs is channel-prefs
(Reporter)

Comment 35

7 years ago
so i tried on a laptop which has never had firefox installed and the keyword.url value is blank
(Reporter)

Comment 36

7 years ago
dont think i can help you anymore henrik unless the firefox.js file will magically appear soon in that folder
(Reporter)

Comment 37

7 years ago
oh i just found the omni.jar file in c drive/program files/mozilla firefox

let me know if you want me to upload it to mediafire
(Reporter)

Comment 38

7 years ago
i opened up omni.jar and it has

firefox.js
firefox-branding.js
firefox.l10n.js
services-sync.s
(Reporter)

Comment 39

7 years ago
ill neaten up all those comments into one

- i tried a new account, no difference because all my programs reappeared
- i tried RC1 on a laptop which has never had firefox installed and it worked, the keyword.url value was blank
- can i upload the omni.jar file to mediafire or another host?
(In reply to comment #26)
> I will check how to reproduce this issue. Christian, is that a regression for
> you compared to Firefox 3.6? Did older beta releases work?

Yes , this is a regression.
I was using 3.6.14 which was working fine and then installed RC1 over it and got the bug.

FF4 Beta 11 and Beta 12 were also working fine.
(In reply to comment #27)
> Christian, can you please open this chrome URL for region.properties and check
> the value for 'browser.search.defaultenginename'? What does it contain? I don't
> see the problem with RC1 (da) on Windows 7. Which platform are you testing on?

What chrome URL ? Be more specific please.

I'm using a Danish WinXP SP3 - the build is Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
(In reply to comment #28)
> Can both of you please run Firefox in Safe Mode
> (http://support.mozilla.com/en-US/kb/Safe%20Mode) to ensure that this problem
> does not exist when all add-ons have been disabled? Thanks.

The problem still exists in safe mode.
So this is somehow related to a pave-over installation when all the files in the 'default/pref' subfolder still exist in Firefox 4. Once those except the channel-prefs.js file get deleted everything works fine. 

I have installed Firefox 4 into the same folder as 3.6.14 was already installed and everything works fine. All those mentioned files have been deleted. So not sure what happened on your box.

Christian, can you please attach the install.log file which you can find in the application directory? It could help us to identify this issue. Also have you used a da version of 3.6 or did you switch the language with the pave-over installation?
Summary: Search in location bar fails and throws an error → 'I'm feeling lucky" search fails after a pave-over installation with old pref files not removed in defaults/pref
It would be great if both of you could test the following and check if it is reproducible for you:

1. Install Firefox 3.6.x and start with a fresh profile
2. Install Firefox 4.0 RC1 over it and use the same profile

Does after step 2 the 'defaults/pref' folder contain more than the channel-prefs.js file? If yes please tell us which locales you have used, if it also happens with en-US, or only with localized builds.
(In reply to comment #44)
I uninstalled and made sure all traces of the previous installation was gone and reinstalled first the da version of 3.6.15 and then upgraded to the da version of RC1.
The problem is gone.

The 'defaults/pref' folder only contain the channel-prefs.js file.
Christian, I have asked for the install.log file. Now that you have reinstalled everything I believe you can't attach this file anymore? I hope you have a backup. That's the most important thing.
Errmm .. yeah. :|
Sorry about that. It's gone now.
Perhaps I could get it back with an undelete program but I highly doubt it's not been overwritten.

I did not switch locales previously. I also upgraded from a da version to a da version.
Yep. It's been overwritten.
s31, do you still have this broken build available? Or have you overwritten it meanwhile too? If not please attach the install.log file from the application folder on this bug. That would be pretty helpful. Otherwise go ahead and upload a rar archive to a place you want.
(Reporter)

Comment 50

7 years ago
i done a fresh install of RC1 yesterday and the only file in default/prefs is channel-prefs.jr is this correct?

i believe it is since i done a fresh install on a laptop which never had FF installed and that was the only file to.

im not sure if it's overwritten, ill attach it anyway..

link: http://www.mediafire.com/?g2h91ih8w2fkeet
pass: henrikbugzilla
A pave-over installation (ie running the installer and reusing an existing install dir) will remove files listed in the control file removed-files.in, in particular
 http://hg.mozilla.org/releases/mozilla-2.0/file/FIREFOX_4_0rc1_RELEASE/browser/installer/removed-files.in#l904
(which is all #ifdef MOZ_OMNIJAR, which is true). So it removes the files that moved into omnijar and search works.

A copy-over 'installation', where fx4 is installed to a separate directory and then copied over an older install, doesn't use that. I don't think that's a supported use case.
Summary: 'I'm feeling lucky" search fails after a pave-over installation with old pref files not removed in defaults/pref → 'I'm feeling lucky" search fails after a copying fx4 over fx3 installation, with old pref files not removed in defaults/pref
(In reply to comment #51)
> A copy-over 'installation', where fx4 is installed to a separate directory and
> then copied over an older install, doesn't use that. I don't think that's a
> supported use case.

Given comment 40 the installation happened directly on the old application folder. Christian, can you please confirm?
(Reporter)

Comment 53

7 years ago
any reply to comment 50?
(Reporter)

Comment 54

7 years ago
any answer*
(In reply to comment #53)
> any reply to comment 50?

The only file in defaults/pref should be channel-prefs.js.
(Reporter)

Comment 56

7 years ago
ok thanks juan :)

now just waiting for henrik to find any information out of the files i uploaded..
(In reply to comment #52)
> (In reply to comment #51)
> Given comment 40 the installation happened directly on the old application
> folder. Christian, can you please confirm?

Confirming. FF4 RC1 installed in the same folder that 3.6 used (The betas used a different folder which was probably why they weren't affected)
s31, can you please upload an archive of the complete application folder? The uploaded archive sadly doesn't contain the information I was hoping for.

Restoring the summary based on comment 57. Still not sure why those files haven't been removed.
Summary: 'I'm feeling lucky" search fails after a copying fx4 over fx3 installation, with old pref files not removed in defaults/pref → 'I'm feeling lucky" search fails after a pave-over installation with old pref files not removed in defaults/pref
(In reply to comment #58)
> s31, can you please upload an archive of the complete application folder? The
> uploaded archive sadly doesn't contain the information I was hoping for.

And this archive has to be for such a broken application and not the new installation you did yesterday. Thanks.
I decided to check the computer I keep at my parents house and it has the same bug.

The OS is Windows 7 Home Premium (64 bit)
I also upgraded that from a Danish 3.6.14 or .15 to a Danish RC1 on that.
The build is Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

I'll attach the install.log from that pc.
Created attachment 519999 [details]
install.log from an affected install
Attachment #519999 - Attachment mime type: application/octet-stream → text/plain
Thanks Christian. Do you have a change to archive the application folder and upload somewhere? I would like to have a detailed look at all those files.
(Reporter)

Comment 64

7 years ago
ah damn thats all i got, my install is now fine...
Thanks Christian! Your application folder is very helpful and I can reproduce it now. Even a downgrade to 3.6.15 and another upgrade to 4.0 RC1 doesn't fix it. The old folders are still present. Not sure yet why that happens, the permissions to remove folders exist.
Status: REOPENED → NEW
Wait, that was too early spoken. A downgrade and upgrade fixes it but when I install 4.0 over this 4.0 version the problematic folders persist.
(Reporter)

Comment 67

7 years ago
nice work henrik, is this going to be fixed by the final release?
So somehow those files which should be removed are not listed in the uninstall/uninstall.log. Given that the uninstaller doesn't know about those folders and doesn't remove those before the new version is installed. So the question is why aren't those files listed there.

Christian, can you please attach the updates.xml file from the following folder? Would be good to know which updates have been installed so far:

C:\Users\<Username>\AppData\Local\Mozilla\Firefox\Mozilla Firefox\updates.xml
Christian, I assume you don't have a backup of the previously 3.6.x build which was installed before you upgraded to RC1?
(Reporter)

Comment 70

7 years ago
mine only goes to C:\Users\<Username>\AppData\Local\Mozilla > Firefox > then it has my default profile

not Mozilla\Firefox

same thing for your christian?
(Reporter)

Comment 71

7 years ago
typo in comment 70, read this one instead.

mine only goes to C:\Users\<Username>\AppData\Local\Mozilla\Firefox\then it
has my default profile

not Mozilla Firefox\updates.xml

same thing for your christian?
(In reply to comment #51)
> A pave-over installation (ie running the installer and reusing an existing
> install dir) will remove files listed in the control file removed-files.in, in
> particular
We uninstall what was previously installed using the uninstall.log now so we no longer have to update older branches removed-files.in.
> Christian, can you please attach the updates.xml file

No such file exist anywhere on my harddrive - i even checked for similarly spelled filenames.
(In reply to comment #71)
> typo in comment 70, read this one instead.
> 
> mine only goes to C:\Users\<Username>\AppData\Local\Mozilla\Firefox\then it
> has my default profile
> 
> not Mozilla Firefox\updates.xml
> 
> same thing for your christian?

Yes. Same.
(In reply to comment #69)
> Christian, I assume you don't have a backup of the previously 3.6.x build which
> was installed before you upgraded to RC1?

You assume correctly. I could do a backup of my other 3.6.x installs on my other PCs (I'm a hardware-geek and have many PCs) and then upgrade them to RC1 and hope they exhibit the same bug, but I'm a little busy ATM so it may take some days.
A shame I'm not at work (I'm on holiday) as I have an entire testlab set up in my office (I'm a software-tester)

I'll get back to you on that.
I just installed RC2 (over a Danish 3.6.15) on my parents laptop and it did not develop the bug.
I also installed the Danish RC2 over RC1 on my Windows 7 pc (from earlier .. the one I 7z'd and posted on 2shared) and the bug did not go away on that PC.
(Reporter)

Comment 77

7 years ago
i installed RC2 over fine
Looks like that something went wrong with the installation of an old 3.6.x build of Firefox on both of your systems. Which resulted that the uninstall.log file contained only a part of all the files to be removed by the uninstaller. Looks like it will be kinda hard to figure out the real issue without having such a broken 3.6.x installation. I hope that someone else will experience the same issue. Until then we should close this bug as incomplete.
Status: NEW → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → INCOMPLETE
I managed to reproduce the bug on my work pc and I remembered to do a backup before I upgraded.

Here is the before and after :
http://www.2shared.com/file/3jeo3tH9/Mozilla_Firefox_3613_bugged.html
http://www.2shared.com/file/h7kHJbMy/Mozilla_Firefox_4_bugged.html
I've also seen the bug on two other pcs, but neither user had taken a backup.
I get the feeling that this bug is not that uncommon.
Rob, how do we operate on the uninstall.log file when doing an application upgrade? The given application folder for Firefox 3.6.13 doesn't contain a uninstall.log file inside the uninstall folder, but an uninstall.update file with the following content only:

File: \freebl3.chk
File: \nssdbm3.chk
File: \softokn3.chk

The given application is a Firefox 3.6.6 installation and has then always been updated. A pave-over installation of Firefox 4 will have no idea of the old files to delete and will cause such a broken application folder.

It seems like we should move this bug to Toolkit:Application Update.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
(In reply to comment #81)
> Rob, how do we operate on the uninstall.log file when doing an application
> upgrade?
It doesn't. The files removed are listed in removed-files.in.

> The given application folder for Firefox 3.6.13 doesn't contain a
> uninstall.log file inside the uninstall folder, but an uninstall.update file
> with the following content only:
If it doesn't contain an uninstall.log then the user likely deleted it using a utility to delete log files on the system. Bug 577563 is to rename or remove the file extension so users don't accidentally shoot themselves in the foot.

> 
> File: \freebl3.chk
> File: \nssdbm3.chk
> File: \softokn3.chk
> 
> The given application is a Firefox 3.6.6 installation and has then always been
> updated. A pave-over installation of Firefox 4 will have no idea of the old
> files to delete and will cause such a broken application folder.

> It seems like we should move this bug to Toolkit:Application Update.
Definitely not. As stated, application update doesn't use the uninstall.log.

As for the installer, if the user deletes files then they will get unexpected behavior and that includes the uninstall.log.
btw: one other scenario that will make it so there is no uninstall.log on Windows is using a zip build
Christian and s31, are you both using a tool to clean-up the disk from log files on the affected machines? Or do you have used zip builds of Firefox in that folder?
To clean up the disk I use Purera, CCleaner and Advanced SystemCare Free
Purera and CCleaner does not remove the log file.
Neither does Advanced SystemCares normal cleaner but it also includes a accessory tool called Disk Cleaner which does remove the uninstall.log unless you are careful.

I don't normally use that tool, but I can't say that I haven't for sure.
Maybe.
I have not used zip builds.
Christian, do those tools also exist on the other machines where you have spotted this issue?
On the 3 of my own PCs and on one of my friends pc that I have seen the bug on -  yes they do. On my work pc that I uploaded the 3.6.13 build, I'm not so sure. I can check but I'm on vacation now and won't be back for yet another week.
Thanks Christian. So I would assume that this is the real problem here and that in all of your cases the uninstall.log has been removed by that tool. As Rob pointed out, a fix for bug 577563 would help us here.

Otherwise its invalid due to an external influence.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → INVALID
Summary: 'I'm feeling lucky" search fails after a pave-over installation with old pref files not removed in defaults/pref → If the uninstall.log file has been removed, a pave-over installation of Firefox 4 will not remove all old files and causes the 'I'm feeling lucky" search to fail
Have you considered changing the (un)installer to be more aggressive so something unforeseen like this would not happen again?

If instead of blacklisting a list of files to be removed, it blacklisted entire directories to remove or it deleted everything in the Firefox folder except whitelisted files and directories?
Changing the name of the file as in bug 577563 should be more than adequate to resolve this.
Duplicate of this bug: 647616
Will fixing bug 577563 also resolve the problem if the user used a zip build ?
We have always required zip users to delete the install directory to uninstall the same as with Mac and Linux. I haven't read all of the comments so if steps to reproduce for a zip build are in a comment let me know which comment or you can provide steps to reproduce with a zip build and I'll take a look.

Comment 95

7 years ago
Hi there I am encountering a similar issue with 4.0 fr installed on my Mac OS snow Leopard without touching/removing the preferences of my previous 3.6.(4?) version.

When I type something in adress bar then enter it just prepends the following:
jar:file:///Applications/Firefox.app/Contents/MacOS/omni.jar!/chrome/fr/locale/browser-region/region.propertiestwitter

(twitter was the thing I typed)

Am I any useful providing logs/more details?
Florent, how have you installed Firefox 4.0 on your system? Can you upload the application bundle somewhere so we can have a look at it? Thanks.

Comment 97

7 years ago
Btw it wasn't behaving the same way 2 days ago.

Comment 98

7 years ago
Yes this is with Firefox 4.0
Well I have a ftp what do you exactly want me to upload:
- The Application in /Applications/
- Preferences Files
- both?

Comment 99

7 years ago
Should have precised 4.0.1 !
Or do you want the .dmg ? Or installation log (where to find it)?
We need an archive of the Firefox.app bundle. Also please tell us how you have installed 4.0.1 (4.0) and which version you had before.

Comment 102

7 years ago
Here it is:
ftp://ftpa.ec-nantes.fr/user/fbuisson/Firefox.zip

For the installation I just downloaded the dmg package from http://www.mozilla-europe.org/fr/ and then replaced the Firefox 3.6.4 Firefox.app I add with the new one, without any regards for cleaning the previous one well.
I have tested your build but it looks fine. Florent can you please try a fresh profile with your steps? Could be a setting which is related to your existent profile. 

http://support.mozilla.com/en-US/kb/Managing+profiles

Comment 104

7 years ago
Indeed with a fresh profile everything works fine.
Can you please backup your default profile or copy its content into the newly created one and move some files out of the folder while Firefox is closed? Then start Firefox and check again. Repeat that until you have found the problematic file of the profile. I would propose you start with 'prefs.js'.

Comment 106

7 years ago
Removing prefs.js solved like you said solved the problem.
Note that the lines quite similar to the thing I had prepended in front of my searches in adresses are:
prefs.js:user_pref("extensions.ecosia.keywordURL", "chrome://browser-region/locale/region.properties");
prefs.js:user_pref("keyword.URL", "chrome://browser-region/locale/region.properties");

Comment 107

7 years ago
I made some tests and just removing the dot in this line of prefs.js :
prefs.js:user_pref("keywordURL", "chrome://browser-region/locale/region.properties");

makes it work fine again !
(In reply to comment #107)
> I made some tests and just removing the dot in this line of prefs.js :
> prefs.js:user_pref("keywordURL",
> "chrome://browser-region/locale/region.properties");

I would assume the extension named 'ecosia' did a bad job here and wrongly set the keyword.URL preference. That pref should normally be empty. That's why it will work after renaming it. You could prove that probably with a fresh profile and installing Ecosia again. If that's the case you should get in contact with the add-on author. Thanks!
You need to log in before you can comment on or make changes to this bug.