STR: Search for something that you have searched for that will return more than 1 item from your search cache. in my case I put int for international In the screenshot attached shows the tips of the letters on the next line but they arent really shown. Application Basics Name Firefox Version 20.0a1 User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20121208 Firefox/20.0 Build Configuration about:buildconfig Extensions Name Version Enabled ID Firebug 1.11.0 true firebug@software.joehewitt.com Important Modified Preferences Name Value accessibility.typeaheadfind.flashBar 0 browser.cache.disk.capacity 1048576 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.places.smartBookmarksVersion 4 browser.startup.homepage_override.buildID 20121208030937 browser.startup.homepage_override.mstone 20.0a1 dom.mozApps.maxLocalId 1001 dom.mozApps.runUpdate false dom.mozApps.used true extensions.lastAppVersion 20.0a1 gfx.blacklist.webgl.msaa 4 network.cookie.prefsMigrated true places.database.lastMaintenance 1354576202 places.history.expiration.transient_current_max_pages 104858 plugin.disable_full_page_plugin_for_types application/pdf print.macosx.pagesetup-2 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIHBsaXN0IFBVQkxJQyAiLS8vQXBwbGUvL0RURCBQTElTVCAxLjAvL0VO privacy.cpd.cookies false privacy.cpd.downloads false privacy.cpd.formdata false privacy.cpd.history false privacy.cpd.offlineApps true privacy.cpd.sessions false privacy.sanitize.migrateFx3Prefs true privacy.sanitize.timeSpan 0 security.warn_viewing_mixed false Graphics Device ID 0x 166 GPU Accelerated Windows 2/2 OpenGL Vendor ID 0x8086 WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce GT 650M OpenGL Engine AzureCanvasBackend quartz AzureContentBackend none AzureFallbackCanvasBackend none JavaScript Incremental GC true Accessibility Activated false Prevent Accessibility 0 Library Versions Expected minimum version Version in use NSPR 4.9.4 4.9.4 NSS 3.14.1.0 Basic ECC Beta 3.14.1.0 Basic ECC Beta NSSSMIME 3.14.1.0 Basic ECC Beta 3.14.1.0 Basic ECC Beta NSSSSL 3.14.1.0 Basic ECC Beta 3.14.1.0 Basic ECC Beta NSSUTIL 3.14.1.0 Beta 3.14.1.0 Beta

I've heard a few reports of something like this, but am having difficulty reproducing it - the search history displays fine for me (see screenshot), without clipping or truncation. Could you try a fresh profile, to see if that makes any difference? Does this persist in all windows, and regardless of resizing, or is it specific to a particular window/size/position? Does it persist across a browser restart?

One thing I forgot to mention was screenshot was on my 24" monitor going through the thunderbolt port. when I do the same on my rMBP screen it shows more. Will try new profile now

When I use a fresh profile it appears to fix it and even going back into old profiles has made it work again which is really weird. I have been restarting the browser when new updates are available so not sure what that could mean

Presumably that means you're now on a slightly newer build. Could you please try reverting to the 2012-12-08 nightly[1] (as in comment #0), and see if the problem reappears? You should be able to run it straight from the mounted disk image, no need to replace your installed version. [1] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-12-08-03-09-37-mozilla-central/

I havent had chance to roll back yet but the latest nightly is starting to shows signs of it back. My laptop did go to sleep and then wake up. I didnt unplug anything so when it woke it started using 2 screens again. I did have an weird issue where it suddenly rendered the drop down on my laptop screen and not on my main monitor and when i deleted some chars it moved it to the middle of the browser. I couldn't reproduce it.

This bug occurs AFAICS, only if you have 2 screens, a lo-dpi screen and a hi-dpi screen. As described by Glen in Bug 814434 comment #13 you have to "Enter a term in the search box which isn't already in the list". So to reproduce this bug, you have to move ff window on a lo-dpi screen and enter something into your google search bar that you have never entered before, something like "test dsfjhkjh" and press enter to search for it. If you enter something new into the search box, the suggestion box has a height of only one row. Once a box is "broken" (it has height of 1 row), you have to restart ff, if you want a non broken box in this context (a form, the google search engine bar or whatever).

I can also observe a similar behavior on FF 19 (aurora), but only if you have this screen configuration: lo-dpi screen must be right of hi dpi screen

If it is important, on those ff 19 aurora versions occured the bug: - 19.0a2 (2012-11-28) - 19.0a2 (2012-12-12)

I was able to reliably reproduce at least one form of this bug, and tracked it down to getting an unexpected value for backingScaleFactor from the popup window when its height collapses to zero. This patch works around the problem by avoiding the problematic NSWindow method and querying the screen instead when the window has a zero dimension (see also comments in code).

Tryserver build is available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-ec254337e7ba/try-macosx64/, if people would like to confirm whether it fixes the problem(s) here in all your various configurations. (I'm confident it fixes at least some of the problems! But it's possible there are further issues still to be tracked down...)

I can confirm that all problems, that i could confirm before, are fixed in your latest tryserver build. I've tested hi.dpi screen is left of lo-dpi screen and vice versa.

Comment on attachment 691907 [details] [diff] [review] work around potentially misleading backingScaleFactor returned by windows with zero area Review of attachment 691907 [details] [diff] [review]: ----------------------------------------------------------------- ::: widget/cocoa/nsCocoaWindow.mm @@ +1464,5 @@ > + } > + if (frame.size.height == 0) { > + frame.origin.y -= 1; > + frame.size.height = 2; > + } Wouldn't it be simpler and slightly more correct to leave the origin alone and set the width/height to 1?

For some reason, I was thinking that if I was inflating the window rect, I should do it in both directions so as to not shift its "centre of gravity". But on second thought, I'm not sure that's really necessary or helpful.