Closed Bug 427028 Opened 16 years ago Closed 4 years ago

firefox lacks hooks to properly upgrade through packging system (Was: After upgrade in ubuntu address bar sometimes triggers "ASSERT: *** Search: _installLocation: engine has no file!" instead of loading URL)

Categories

(Firefox :: Search, enhancement, P4)

3.0 Branch
enhancement

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jbeheler, Unassigned)

References

Details

(Whiteboard: [fxsearch])

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

Error Message:
ASSERT: *** Search: _installLocation: engine has no file!
Stack Trace: 
0:ENSURE_WARN(false,_installLocation: engine has no file!,2147500037)
1:()
2:()
3:()
4:epsGetAttr([object Object],alias)
5:()
6:SRCH_SVC_getEngineByAlias(https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided)
7:getEngineByAlias(https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided)
8:getShortcutOrURI(https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided,[object Object])
9:canonizeUrl([object KeyboardEvent],[object Object])
10:handleURLBarCommand([object KeyboardEvent])
11:anonymous(textentered,[object KeyboardEvent])
12:fireEvent(textentered,[object KeyboardEvent])
13:onTextEntered()
14:handleEnter(false)
15:onKeyPress([object KeyboardEvent])
16:onxblkeypress([object KeyboardEvent])


Reproducible: Always

Steps to Reproduce:
1.  Press Cmd+L (or single/double click the location bar)
2.  Enter the URL you would like to navigate to
3.  Press Enter and the error pops up.
Actual Results:  
Cannot navigate to the requested page. Error is seen in new tabs and even when trying to create a new window.

Expected Results:  
Firefox 3 should navigate to the page requested.

I'm using Firefox 3b5 with a few add-ons of which I cannot verify right now.  I know one is Stylish.
Can you try with a clean profile?  If you don't see the bug while using a clean profile, please try to figure out what extension(s) or other settings are necessary to trigger the bug.
Severity: normal → major
Summary: Trying to manually type a location in the address bar is failing → Pressing enter in address bar triggers "ASSERT: *** Search: _installLocation: engine has no file!" instead of loading URL
I believe this bug is triggered by upgrading Firefox when it is running.  I installed Fedora Linux 9, which includes Firefox 3.0b5, and started Firefox and opened some tabs and web pages.  Then I ran the Fedora 'yum update' command which upgraded Firefox to 3.0 using the rpm package system.  After that, trying to use Firefox kept triggering assertion failures when entering text in the search box or switching between tabs.  The assertion failures are similar to that at the top of this bug report.  Here are two of them:

ASSERT: *** Search: _installLocation: engine has no file!
Stack Trace: 
0:ENSURE_WARN(false,_installLocation: engine has no file!,2147500037)
1:()
2:()
3:()
4:epsGetAttr([object Object],alias)
5:()
6:SRCH_SVC_getEngineByAlias(https://bugzilla.redhat.com/show_bug.cgi?id=445158)
7:getEngineByAlias(https://bugzilla.redhat.com/show_bug.cgi?id=445158)
8:getShortcutOrURI(https://bugzilla.redhat.com/show_bug.cgi?id=445158,[object Object])
9:canonizeUrl([object KeyboardEvent],[object Object])
10:handleURLBarCommand([object KeyboardEvent])
11:anonymous(textentered,[object KeyboardEvent])
12:fireEvent(textentered,[object KeyboardEvent])
13:onTextEntered()
14:handleEnter(false)
15:onKeyPress([object KeyboardEvent])
16:onxblkeypress([object KeyboardEvent])


ASSERT: *** Search: _installLocation: engine has no file!
Stack Trace: 
0:ENSURE_WARN(false,_installLocation: engine has no file!,2147500037)
1:()
2:()
3:()
4:epsGetAttr([object Object],hidden)
5:()
6:()
7:currentEngine()
8:get_currentEngine()
9:doSearch(firefox bugzilla,current)
10:handleSearchCommand([object KeyboardEvent])
11:onTextEntered()
12:handleEnter(false)
13:onKeyPress([object KeyboardEvent])
14:onxblkeypress([object KeyboardEvent])


The only addons I have installed are the various language packs that ship with Fedora Linux 9.

It appears from the message that some file Firefox uses has been removed as part of the upgrade.  If this is the case, then perhaps assertion failures should not be used as the mechanism to report missing files (after all a file can go away for all sorts of reasons, and an assertion failure indicates a completely 'impossible' condition).  Instead if a file is missing the user could be prompted to restart Firefox.
is this still reproducible?
Looks like a problem in the Fedora upgrade package though...
I have seen this several times since reporting the bug.  It does seem to occur when Firefox is upgraded while it's still running.

I haven't tried to reproduce it, but in general, surely assertions should not be used to check for missing files?  An assertion should be an impossible, 'cannot happen' condition based on program logic, not something that checks the state of the world external to the program.  After all filesystems can be unmounted, files can be deleted, and while this is certainly an error condition it is not an impossible condition.

I suppose you could talk to the Fedora guys about what is the supported way to upgrade Firefox, and if the user should be prompted to restart the browser when a new rpm package is pushed out.
Can someone please mark this as a duplicate of bug #457434.
Summary: Pressing enter in address bar triggers "ASSERT: *** Search: _installLocation: engine has no file!" instead of loading URL → firefox lacks hooks to properly upgrade through packging system (Was: After upgrade in ubuntu address bar sometimes triggers "ASSERT: *** Search: _installLocation: engine has no file!" instead of loading URL)
lets use this as the main bug to track progress on firefox integrating with packaging system. This probably will take some time, so don't expect a fix to happen anytime soon.

To workaround you have to restart all firefox instances; unfortunatly only way for users to be sure that you really restarted firefox is to relogin or even reboot.

See ubuntu bug: https://bugs.edge.launchpad.net/bugs/338785
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Location Bar and Autocomplete → Application Update
Product: Firefox → Toolkit
QA Contact: location.bar → application.update
Severity: major → enhancement
OS: Mac OS X → Linux
Hardware: PowerPC → All
Application update is for the Mozilla application update component and not any distro's packaging component. Moving it back to the previous component
Component: Application Update → Location Bar and Autocomplete
Product: Toolkit → Firefox
QA Contact: application.update → location.bar
As given by bug 466278 this happens when a search engine file has been removed/renamed while Firefox is running. As stated by Gavin it's a bug in the search service.
Component: Location Bar and Autocomplete → Search
OS: Linux → All
QA Contact: location.bar → search
Version: unspecified → 3.0 Branch
I suspect Mozilla's thinking goes something like this:
"everybody should use our autoupdater, which handles this problem properly.  
Using the Linux package manager to update firefox is broken because it will change
files out from under Firefox."

But you can write a browser to be insensitive to files changing.
The way we solved it in Chrome for Linux was to open all the
files the browser would ever need right at startup, and if we needed to launch
another copy of the executable, do it with fork() and not exec().
See http://code.google.com/p/chromium/wiki/LinuxZygote

It would be nice if Firefox did something similar.
Priority: -- → P4
Whiteboard: [fxsearch]
Rank: 45

It is unclear if this is still an issue or not, but seeing as there haven't been complaints in recent years, I will assume this has either been worked around or fixed. So for now I'll resolve it.

If this is still an issue, I'm happy to talk about options to resolve it.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.