Awesome bar is extremely slow in Firefox 47 / 48

RESOLVED DUPLICATE of bug 1283329

Status

()

Firefox
Address Bar
RESOLVED DUPLICATE of bug 1283329
2 years ago
a year ago

People

(Reporter: p8k9mm, Unassigned)

Tracking

48 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160604131506

Steps to reproduce:

The new awesome bar is extremely slow in when presenting completion suggestions.  Type a letter, wait 3-10 seconds for the list to come up. Type a second letter to further refine the selection, wait another 3-10 seconds for the list to be updated. And so on.

In versions of Firefox prior to version 47, typing a letter in the awesome bar would instantaneously (or very nearly so) bring up a list of completion suggestions. In Version 47, setting browser.urlbar.unifiedcomplete to false resolved the problem with the slowdown. However, in version 48 the awesome bar is always slow regardless of the setting of browser.urlbar.unifiedcomplete.

Running Firefox in Safe Mode does not resolve the problem.

Based on what I'm seeing, it looks like the algorithm used to calculate the completion suggestions is orders of magnitude slower than it used to be.


Actual results:

Each letter typed in the awesome bar causes a 3 - 10 second delay while the list of suggestions is updated.


Expected results:

The list of suggestions should be updated nearly instantaneously.

Updated

2 years ago
Component: Untriaged → Location Bar
(In reply to p8k9mm from comment #0)
> The new awesome bar is extremely slow in when presenting completion
> suggestions.  Type a letter, wait 3-10 seconds for the list to come up. Type
> a second letter to further refine the selection, wait another 3-10 seconds
> for the list to be updated. And so on.

Please attach a log from your about:support page.

Could you please try Firefox 49 Beta and tell me if it improves things? It contains some performance fixes that may help a lot certain cases.

If that doesn't help, please try https://addons.mozilla.org/en-US/firefox/addon/places-maintenance/ to be sure your database is sane and attach here the log that it prints at the end.

Updated

2 years ago
Flags: needinfo?(p8k9mm)
(Reporter)

Comment 2

2 years ago
I tried Firefox 49 Beta. No improvement.

Information from about:support. Sorry about the appearance. Cutting and pasting from a table to plain text doesn't end up looking very good.

Application Basics 
Name 
Firefox
Version 
48.0.2
Build ID 
20160823121617
Update History 
Show Update History 
Update Channel 
release
User Agent 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0
OS 
Darwin 15.6.0 x86-64
Profile Folder 
Show in Finder 
Enabled Plugins 
about:plugins 
Build Configuration 
about:buildconfig 
Memory Use 
about:memory 
Registered Service Workers 
about:serviceworkers 
Multiprocess Windows 
0/11 (Disabled)
Safe Mode 
false
Profiles 
about:profiles 
Crash Reports for the Last 3 Days
Report ID 
Submitted 

All Crash Reports 
This application has not been configured to display crash reports.
Extensions 
Name 
Version 
Enabled 
ID 
Classic Theme Restorer
1.5.2
true
ClassicThemeRestorer@ArisT2Noia4dev
Firefox Hello
1.4.4
true
loop@mozilla.org
Multi-process staged rollout
1.1
true
e10srollout@mozilla.org
Pocket
1.0.4
true
firefox@getpocket.com
Video DownloadHelper
5.6.1
true
{b9db16a4-6edc-47ec-a1f4-b86292ed211d}
Places Maintenance
2.0.2
false
places-maintenance@bonardo.net
Graphics 
Features 
Compositing
OpenGL
Asynchronous Pan/Zoom
none
WebGL Renderer
Intel Inc. -- Intel HD Graphics 4000 OpenGL Engine
Hardware H264 Decoding
Yes

GPU #1 
Active
Yes
Vendor ID
0x8086
Device ID
0x0166
Diagnostics 
AzureCanvasAccelerated
1
AzureCanvasBackend
skia
AzureContentBackend
skia
AzureFallbackCanvasBackend
none
Important Modified Preferences 
Name 
Value 
accessibility.typeaheadfind.flashBar
0
browser.cache.disk.capacity
358400
browser.cache.disk.filesystem_reported
1
browser.cache.disk.hashstats_reported
1
browser.cache.disk.smart_size_cached_value
358400
browser.cache.disk.smart_size.first_run
false
browser.cache.disk.smart_size.use_old_max
false
browser.cache.frecency_experiment
4
browser.cache.memory.capacity
32768
browser.download.importedFromSqlite
true
browser.download.manager.closeWhenDone
true
browser.download.manager.retention
0
browser.download.useDownloadDir
false
browser.places.importBookmarksHTML
false
browser.places.smartBookmarksVersion
8
browser.sessionstore.max_tabs_undo
5
browser.sessionstore.upgradeBackup.latestBuildID
20160823121617
browser.startup.homepage
about:blank
browser.startup.homepage_override.buildID
20160823121617
browser.startup.homepage_override.mstone
48.0.2
browser.tabs.drawInTitlebar
false
browser.tabs.onTop
false
browser.urlbar.default.behavior
1
browser.urlbar.suggest.bookmark
false
browser.urlbar.suggest.openpage
false
browser.urlbar.unifiedcomplete
false
browser.urlbar.userMadeSearchSuggestionsChoice
true
dom.apps.lastUpdate.buildID
20160902105049
dom.apps.lastUpdate.mstone
49.0
dom.apps.reset-permissions
true
dom.mozApps.used
true
dom.w3c_touch_events.expose
false
extensions.lastAppVersion
48.0.2
font.internaluseonly.changed
true
font.size.variable.x-western
14
gfx.blacklist.direct2d
3
gfx.blacklist.direct2d.failureid
FEATURE_FAILURE_DL_BLACKLIST_g984
gfx.crash-guard.glcontext.appVersion
45.0.2
gfx.crash-guard.glcontext.deviceID
0x0166
gfx.crash-guard.status.glcontext
2
media.benchmark.vp9.fps
143
media.benchmark.vp9.versioncheck
1
media.gmp-gmpopenh264.abi
x86_64-gcc3-u-i386-x86_64
media.gmp-gmpopenh264.enabled
false
media.gmp-gmpopenh264.lastUpdate
1453393401
media.gmp-gmpopenh264.version
1.5.3
media.gmp-manager.buildID
20160823121617
media.gmp-manager.lastCheck
1473482783
media.gmp-widevinecdm.abi
x86_64-gcc3-u-i386-x86_64
media.gmp-widevinecdm.lastUpdate
1465352152
media.gmp-widevinecdm.version
1.4.8.866
media.gmp.storage.version.observed
1
mousewheel.with_alt.action
1
mousewheel.with_control.action
1
mousewheel.with_meta.action
1
network.cookie.cookieBehavior
1
network.cookie.prefsMigrated
true
network.predictor.cleaned-up
true
places.database.lastMaintenance
1472818077
places.history.expiration.transient_current_max_pages
104858
plugin.disable_full_page_plugin_for_types
application/pdf
plugin.importedState
true
plugin.state.amazonmp3downloaderplugin
0
plugin.state.couponprinter-firefox
0
plugin.state.default browser
0
plugin.state.directorshockwave
0
plugin.state.flash
0
plugin.state.flip4mac wmv plugin
0
plugin.state.garmingpscontrol
0
plugin.state.google earth web plug-in
0
plugin.state.googletalkbrowserplugin
0
plugin.state.iphotophotocast
0
plugin.state.o1dbrowserplugin
0
plugin.state.officelivebrowserplugin
0
plugin.state.quicktime plugin
0
plugin.state.realplayer plugin
0
plugin.state.rhapsodyplayerengine
0
plugin.state.silverlight
0
print.print_bgcolor
false
print.print_bgimages
false
print.print_colorspace

print.print_command

print.print_downloadfonts
true
print.print_duplex
1
print.print_evenpages
true
print.print_in_color
true
print.print_margin_bottom
0.5
print.print_margin_left
0.5
print.print_margin_right
0.5
print.print_margin_top
0.5
print.print_oddpages
true
print.print_orientation
0
print.print_page_delay
50
print.print_pagedelay
500
print.print_paper_data
0
print.print_paper_height
11.00
print.print_paper_name

print.print_paper_size
7995424
print.print_paper_size_type
1
print.print_paper_size_unit
0
print.print_paper_width
8.50
print.print_plex_name

print.print_printer

print.print_resolution
73901940
print.print_resolution_name

print.print_reversed
false
print.print_scaling
1.00
print.print_shrink_to_fit
true
print.print_to_file
false
print.print_unwriteable_margin_bottom
56
print.print_unwriteable_margin_left
25
print.print_unwriteable_margin_right
25
print.print_unwriteable_margin_top
25
privacy.cpd.cookies
false
privacy.cpd.downloads
false
privacy.cpd.formdata
false
privacy.cpd.history
false
privacy.cpd.sessions
false
privacy.donottrackheader.enabled
true
privacy.popups.showBrowserMessage
false
privacy.sanitize.migrateClearSavedPwdsOnExit
true
privacy.sanitize.migrateFx3Prefs
true
privacy.sanitize.timeSpan
0
security.enable_java
false
security.warn_viewing_mixed
false
services.sync.declinedEngines

storage.vacuum.last.index
1
storage.vacuum.last.places.sqlite
1472068821
user.js Preferences
Your profile folder contains a user.js file, which includes preferences that were not created by Firefox.
Important Locked Preferences 
Name 
Value 

JavaScript 
Incremental GC 
true
Accessibility 
Activated 
false
Prevent Accessibility 
0
Library Versions 

Expected minimum version
Version in use
NSPR
4.12
4.12
NSS
3.24 Basic ECC
3.24 Basic ECC
NSSSMIME
3.24 Basic ECC
3.24 Basic ECC
NSSSSL
3.24 Basic ECC
3.24 Basic ECC
NSSUTIL
3.24
3.24
Experimental Features 
Name 
ID 
Description 
Active 
End Date 
Homepage 
Branch
Flags: needinfo?(p8k9mm)
(Reporter)

Comment 3

2 years ago
In version 47, the browser.urlbar.unifiedcomplete setting can be toggled back and forth, switching between fast operation of the completion suggestions and the slow operation documented in this bug report. (No restarting of Firefox is needed, just the changing of the setting.) In version 48, the browser.urlbar.unifiedcomplete setting has no effect on the performance (always slow).
(Reporter)

Comment 4

2 years ago
Additional information:

The slow response I’ve reported in this bug report seems to occur mostly when modifying a URL already in the awesome bar. Not when typing something from scratch.

For example, if I type "b" in an empty (blank) awesome bar, followed by "e", followed by the delete key, followed by "a", after each keystroke the list of suggestions is usually updated very quickly. (Not always, however. Deleting a character can at times cause a significant slowdown in updating the list of suggestions. But that’s an issue separate from what I’m reporting in this bug report.)

But if (for example) "https://www.youtube.com/user/BaratsAndBereta/" appears in the awesome bar and I highlight "BaratsAndBereta/" and change it to "B", the suggestion list is slow to update (3-10 seconds). If I then type “a”, the list is again very slow to update. And so on. However, if I delete the entire URL and type "B" from scratch, the list is updated quickly. If I then type "a", it’s once again updated quickly.
(In reply to p8k9mm from comment #3)
> the browser.urlbar.unifiedcomplete setting has no effect on the
> performance (always slow).

The pref was only temporary to ensure the feature was working properly for most users before enabling it. it has been removed in the meanwhile.

I see that you have only history enabled for the awesomebar. This may be an interesting point to take into account.

(In reply to p8k9mm from comment #4)
> But if (for example) "https://www.youtube.com/user/BaratsAndBereta/" appears
> in the awesome bar and I highlight "BaratsAndBereta/" and change it to "B",
> the suggestion list is slow to update (3-10 seconds). If I then type “a”,
> the list is again very slow to update.

I will see if I can get something out of these STR.
Flags: needinfo?(mak77)

Updated

2 years ago
Blocks: 1279864

Comment 6

2 years ago
FF47?
That has the same urlbar since ages. Only FF48 brings the redesigned urlbar.
Something to investigate for things looking like uris.
matchKnownUrl says:

      if (lastSlashIndex < this._searchString.length - 1) {
        // We don't want to execute this query right away because it needs to
        // search the entire DB without an index, but we need to know if we have
        // a result as it will influence other heuristics. So we guess by
        // assuming that if we get a result from a *host* query and it *looks*
        // like a URL, then we'll probably have a result.
        let gotResult = false;
        let [ query, params ] = this._urlQuery;
        yield conn.executeCached(query, params, row => {

we are directly running an urlQuery and not first checking if we know the host.
since here we can't use an index, the query may take more time than we would like.
Unfortunately we don't have many easy ways to improve this, even running an host query as suggested would only speed up cases where we don't know about the url.
All of this is needed for the "complete url to the next slash" feature.

Updated

2 years ago
See Also: → bug 1283329
I'm going to handle this in bug 1283329. The problem appears to be different than what I was expecting here.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(mak77)
Resolution: --- → DUPLICATE
Duplicate of bug: 1283329
(Reporter)

Comment 9

2 years ago
As of Firefox 50.0 this problem remains unfixed. The awesome bar is still noticeably slow. There has been only a slight performance improvement from version 48. It is still much "laggier" than version 47.
(In reply to p8k9mm from comment #9)
> As of Firefox 50.0 this problem remains unfixed. The awesome bar is still
> noticeably slow. There has been only a slight performance improvement from
> version 48. It is still much "laggier" than version 47.

that's likely bug 1319727 that happens in specific situations and we'll fix it asap. I think the "laggier" behavior is mostly a matter of perception than a real bug, the fact is that it was previously blocking main-thread, so causing slight jank, but then reacting a bit faster after that. Now the transition is smoother. Or it could be cause we more aggressively cancel previous queries.
(Reporter)

Comment 11

2 years ago
Thanks for the reply.

I also have seen the behavior described in bug 1319727. And, as is reported in bug 1319727, I also have a large history.

Bug 1319727 reports a delay between pressing RETURN and when the page is loaded, whereas this bug is related to editing text in the wonder bar before pressing RETURN (see the comment I added on "2016-09-10 14:17:53 PDT"), so it’s unclear if they are related.  But since they both seem related to slow access to places.sqlite that’s probably as good of a place to start as any.

This problem started with the newly-redesigned wonder bar in version 47. If I revert back to version 46, the performance of the wonder bar is quick once again.

(By the way, I tried to delete old items from my browser history in an attempt to reduce its size. Unfortunately history deletion is exponentially slower as the number of items deleted increases. See bug 734643. Attempting to prune a large portion of my history would take weeks or months or years of CPU time.)

This bug was marked as a duplicate of bug 1283329 and closed. Since 1283329 did not fix the problem, is there some way to de-associate this bug from 1283329? I couldn’t find a way to do this myself, other than change its status to UNCONFIRMED. (Is that correct thing to do?)
The same visible bugs can have multiple underlying causes, so in general it's unlikely reopening a bug is the right thing to do.

Firefox 51 has not been released yet, did you test with Beta? The fact the bug is marked as fix doesn't mean the fix has been released in the Release channel.

If your issue can be reproduced in Firefox 51 AND you are pretty sure it's not due to a previous search still ongoing (bug 1319727) AND you have reproducible steps to reproduce it, then it's a good idea to open a new bug. Otherwise, you may just follow that bug and see how much things improve once it's fixed.
Ehr, I didn't connect the fact YOU filed this bug originally, so, if the above "requirements" fit, you CAN reopen this bug instead of filing a new one, since it's yours! Sorry for the confusion.
(also note the version just released is 50.1, not 51)
You need to log in before you can comment on or make changes to this bug.