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)
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.
Comment 1•16 years ago
|
||
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.
Comment 3•15 years ago
|
||
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.
Comment 5•15 years ago
|
||
Can someone please mark this as a duplicate of bug #457434.
Updated•15 years ago
|
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)
Comment 7•15 years ago
|
||
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
Updated•15 years ago
|
Component: Location Bar and Autocomplete → Application Update
Product: Firefox → Toolkit
QA Contact: location.bar → application.update
Updated•15 years ago
|
Severity: major → enhancement
Updated•15 years ago
|
OS: Mac OS X → Linux
Hardware: PowerPC → All
Comment 8•15 years ago
|
||
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
Comment 10•15 years ago
|
||
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
Updated•15 years ago
|
See Also: → https://launchpad.net/bugs/338785
Comment 16•13 years ago
|
||
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.
Updated•11 years ago
|
Updated•9 years ago
|
Priority: -- → P4
Whiteboard: [fxsearch]
Updated•9 years ago
|
Rank: 45
Comment 17•4 years ago
|
||
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.
Description
•