820327 - Google Search drop down only rendering first item in dropdown fully and tips of next item

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[David Burns :automatedtester]

Attachment: search only rendering first item properly. 2nd item slightly visible

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
        [e-mail]

  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

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: search drop-down rendered properly

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?

Comment 2

[David Burns :automatedtester]

Attachment: Laptop screen render

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

Comment 3

[David Burns :automatedtester]

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

Comment 4

[Jonathan Kew [:jfkthame]]

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/

Comment 5

[David Burns :automatedtester]

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.

Comment 6

[chrille_b]

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).

Comment 7

[chrille_b]

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

Comment 8

[chrille_b]

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

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: work around potentially misleading backingScaleFactor returned by windows with zero area

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).

Comment 10

[Jonathan Kew [:jfkthame]]

Tryserver build is available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-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...)

Comment 11

[chrille_b]

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 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 13

[Jonathan Kew [:jfkthame]]

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.

Comment 14

[Jonathan Kew [:jfkthame]]

Attachment: work around potentially misleading backingScaleFactor returned by windows with zero area

Comment 15

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/11fd34243cbd

Comment 16

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/11fd34243cbd