New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 334454 link

Starred by 382 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2014
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

No hover styling when hovering over last element in a list of <option>s

Reported by dan.deso...@gmail.com, Jan 14 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36

Example URL:
http://enjoysmile.com/content/options.html

Steps to reproduce the problem:
1. Visit http://enjoysmile.com/content/options.html
2. Click the <select> element
3. Hover over the 7th element (8 - no hover)

What is the expected behavior?
The last element should behave like all others by filling the background upon hovering.

What went wrong?
The last element's background did not get filled upon hovering.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes

Does this work in other browsers? Yes 

Chrome version: 32.0.1700.76  Channel: stable
OS Version: 7 sp1 x64
Flash Version: Shockwave Flash 12.0 r0

I've tested this on 32.0.1700.76 m as well as 34.0.1785.0 canary. I believe this behaviour started as of 32.0.1700.72.

 
Cc: karen@chromium.org ananta@chromium.org zturner@chromium.org pbomm...@chromium.org
Labels: -Type-Bug Type-Bug-Regression M-32
Status: Untriaged
Able to reproduce the issue using bug report steps,This is recent regression 

Manual Chromium Bisect : 
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/branches/1700/src&range=244343:243482&mode=html

Note : Ran manual bisect as bisect script picks revisions where non of the drop down works(issue in M34 and got fixed). Hence did manual bisect.


Other findings :
When we use keyboard down arrow I see "8" gets highlighted.

Note :The same works fine on Win8/8.1 with chrome 32.0.1700.76. It's broken only on 32.0.1700.76.

Comment 3 by ananta@chromium.org, Jan 15 2014

Owner: ananta@chromium.org
Status: Assigned
Taking up for investigation. Strange that it only reproduces on Windows 7. On first glance it may be related to the scrolling fix.

Comment 4 by tkent@chromium.org, Jan 15 2014

Mergedinto: 334227
Status: Duplicate
Project Member

Comment 5 by bugdroid1@chromium.org, Jan 16 2014

------------------------------------------------------------------------
r245051 | ananta@chromium.org | 2014-01-16T01:45:21.217058Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/win/hwnd_message_handler.cc?r1=245051&r2=245050&pathrev=245051
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/win/hwnd_message_handler.h?r1=245051&r2=245050&pathrev=245051

Don't set the scroll styles (WS_VSCROLL and WS_HSCROLL) for WS_POPUP windows.

This causes issues with select boxes on Windows 7 where hovering at the end of the window returns the scroll WM_NCHITTEST
codes. Works fine on Windows 8. In any case we don't want the scrolling styles set on windows other than the main Chrome window
which is the only window which should be receive mousewheel messages.

I moved the scroll style setting code from the HWNDMessageHandler::OnCreate function to HWNDMessageHandler::Init function as that
would prevent the initial WM_SIZE message from hiding the scrollbar. The other change is to hide the scrollbars and readd the
scroll styles if we are sizing the window, when the sizing completes. Basically when we receive the WM_EXITSIZEMOVE message.
For normal sizing operations we continue to do this in WM_SIZE as before.

From testing on my thinkpad with Win7, desktop with Win7 and Win8 this works well.

BUG= 334454 , 334541 
R=sky@chromium.org, sky

Review URL: https://codereview.chromium.org/137403008
------------------------------------------------------------------------
Project Member

Comment 6 by bugdroid1@chromium.org, Jan 16 2014

------------------------------------------------------------------------
r245191 | alph@chromium.org | 2014-01-16T10:02:05.887664Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/win/hwnd_message_handler.cc?r1=245191&r2=245190&pathrev=245191
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/win/hwnd_message_handler.h?r1=245191&r2=245190&pathrev=245191

Revert 245051 "Don't set the scroll styles (WS_VSCROLL and WS_HS..."

Seems to be causing lots of layout test failures on Win7

> Don't set the scroll styles (WS_VSCROLL and WS_HSCROLL) for WS_POPUP windows.
> 
> This causes issues with select boxes on Windows 7 where hovering at the end of the window returns the scroll WM_NCHITTEST
> codes. Works fine on Windows 8. In any case we don't want the scrolling styles set on windows other than the main Chrome window
> which is the only window which should be receive mousewheel messages.
> 
> I moved the scroll style setting code from the HWNDMessageHandler::OnCreate function to HWNDMessageHandler::Init function as that
> would prevent the initial WM_SIZE message from hiding the scrollbar. The other change is to hide the scrollbars and readd the
> scroll styles if we are sizing the window, when the sizing completes. Basically when we receive the WM_EXITSIZEMOVE message.
> For normal sizing operations we continue to do this in WM_SIZE as before.
> 
> From testing on my thinkpad with Win7, desktop with Win7 and Win8 this works well.
> 
> BUG= 334454 , 334541 
> R=sky@chromium.org, sky
> 
> Review URL: https://codereview.chromium.org/137403008

TBR=ananta@chromium.org

Review URL: https://codereview.chromium.org/137443018
------------------------------------------------------------------------
Project Member

Comment 7 by bugdroid1@chromium.org, Jan 16 2014

------------------------------------------------------------------------
r245289 | ananta@chromium.org | 2014-01-16T19:45:14.405278Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/win/hwnd_message_handler.cc?r1=245289&r2=245288&pathrev=245289
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/views/win/hwnd_message_handler.h?r1=245289&r2=245288&pathrev=245289

Relanding this as this caused layout tests failures on Win7 due to the call to ShowScrollBars being incorrectly deleted
in the HWNDMessageHandler::OnSize for a regular WM_SIZE. Added that call back. The rest of the CL is exactly the same as
the previous one. TBR'ing sky.

Don't set the scroll styles (WS_VSCROLL and WS_HSCROLL) for WS_POPUP windows.

This causes issues with select boxes on Windows 7 where hovering at the end of the window returns the scroll WM_NCHITTEST
codes. Works fine on Windows 8. In any case we don't want the scrolling styles set on windows other than the main Chrome window
which is the only window which should be receive mousewheel messages.

I moved the scroll style setting code from the HWNDMessageHandler::OnCreate function to HWNDMessageHandler::Init function as that
would prevent the initial WM_SIZE message from hiding the scrollbar. The other change is to hide the scrollbars and readd the
scroll styles if we are sizing the window, when the sizing completes. Basically when we receive the WM_EXITSIZEMOVE message.
For normal sizing operations we continue to do this in WM_SIZE as before.

From testing on my thinkpad with Win7, desktop with Win7 and Win8 this works well

BUG= 334454 ,  334541 
TBR=sky

Review URL: https://codereview.chromium.org/133273020
------------------------------------------------------------------------

Comment 8 by ananta@chromium.org, Jan 18 2014

Labels: M-33 Merge-Requested

Comment 9 by ananta@chromium.org, Jan 18 2014

Cc: sky@chromium.org smokana@chromium.org
 Issue 334227  has been merged into this issue.

Comment 10 by kareng@google.com, Jan 18 2014

 Issue 334227  has been merged into this issue.

Comment 11 by kareng@google.com, Jan 18 2014

can you check if you're seeing this problem in current Google Chrome Canary? We believe it should be fixed there 34.0.1792.0

Comment 12 by laforge@google.com, Jan 18 2014

 Issue 334227  has been merged into this issue.

Comment 13 by laforge@google.com, Jan 18 2014

Labels: -Merge-Requested Merge-Approved
Approved for M33 (1750)

Comment 14 by dhw@chromium.org, Jan 18 2014

Cc: -ananta@chromium.org
Mergedinto:
Status: Fixed
This isn't the dup if it's got the revision for the code fix.
Fixed on 34.0.1792.0 canary :)
Cc: ranjitkan@chromium.org
Issue is fixed on Chrome 34.0.1794.5 (Official Build 245838) canary, but able to reproduce on chrome 33.0.1750.41 (Official Build 245850).

Comment 17 Deleted

@comment #17
Flagged as fixed does not mean it was pushed to users, it means the bug was fixed and is scheduled to release in next builds.

And if you don't know what the v33 and v34 are, then google it about Canary and Beta channels. v32 is the stable channel, by the way.
 Issue 335504  has been merged into this issue.
 Issue 335545  has been merged into this issue.
 Issue 335572  has been merged into this issue.
ananta, does your fix also fix  issue 334522 ?
ananta, does your fix also fix  issue 334522 ?
Project Member

Comment 24 by bugdroid1@chromium.org, Jan 21 2014

Labels: -Merge-Approved merge-merged-1700
------------------------------------------------------------------------
r246121 | ananta@chromium.org | 2014-01-21T21:41:12.370192Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/ui/views/win/hwnd_message_handler.cc?r1=246121&r2=246120&pathrev=246121
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/ui/views/win/hwnd_message_handler.h?r1=246121&r2=246120&pathrev=246121

Merge 245289 "Relanding this as this caused layout tests failure..."

> Relanding this as this caused layout tests failures on Win7 due to the call to ShowScrollBars being incorrectly deleted
> in the HWNDMessageHandler::OnSize for a regular WM_SIZE. Added that call back. The rest of the CL is exactly the same as
> the previous one. TBR'ing sky.
> 
> Don't set the scroll styles (WS_VSCROLL and WS_HSCROLL) for WS_POPUP windows.
> 
> This causes issues with select boxes on Windows 7 where hovering at the end of the window returns the scroll WM_NCHITTEST
> codes. Works fine on Windows 8. In any case we don't want the scrolling styles set on windows other than the main Chrome window
> which is the only window which should be receive mousewheel messages.
> 
> I moved the scroll style setting code from the HWNDMessageHandler::OnCreate function to HWNDMessageHandler::Init function as that
> would prevent the initial WM_SIZE message from hiding the scrollbar. The other change is to hide the scrollbars and readd the
> scroll styles if we are sizing the window, when the sizing completes. Basically when we receive the WM_EXITSIZEMOVE message.
> For normal sizing operations we continue to do this in WM_SIZE as before.
> 
> From testing on my thinkpad with Win7, desktop with Win7 and Win8 this works well
> 
> BUG= 334454 ,  334541 
> TBR=sky
> 
> Review URL: https://codereview.chromium.org/133273020

TBR=ananta@chromium.org

Review URL: https://codereview.chromium.org/144313002
------------------------------------------------------------------------
Labels: Merge-Requested

Comment 26 by laforge@google.com, Jan 21 2014

Labels: -Merge-Requested Merge-Approved
Project Member

Comment 27 by bugdroid1@chromium.org, Jan 21 2014

Labels: -Merge-Approved merge-merged-1750
------------------------------------------------------------------------
r246169 | ananta@chromium.org | 2014-01-21T23:53:59.415208Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/views/win/hwnd_message_handler.h?r1=246169&r2=246168&pathrev=246169
   M http://src.chromium.org/viewvc/chrome/branches/1750/src/ui/views/win/hwnd_message_handler.cc?r1=246169&r2=246168&pathrev=246169

Merge 245289 "Relanding this as this caused layout tests failure..."

> Relanding this as this caused layout tests failures on Win7 due to the call to ShowScrollBars being incorrectly deleted
> in the HWNDMessageHandler::OnSize for a regular WM_SIZE. Added that call back. The rest of the CL is exactly the same as
> the previous one. TBR'ing sky.
> 
> Don't set the scroll styles (WS_VSCROLL and WS_HSCROLL) for WS_POPUP windows.
> 
> This causes issues with select boxes on Windows 7 where hovering at the end of the window returns the scroll WM_NCHITTEST
> codes. Works fine on Windows 8. In any case we don't want the scrolling styles set on windows other than the main Chrome window
> which is the only window which should be receive mousewheel messages.
> 
> I moved the scroll style setting code from the HWNDMessageHandler::OnCreate function to HWNDMessageHandler::Init function as that
> would prevent the initial WM_SIZE message from hiding the scrollbar. The other change is to hide the scrollbars and readd the
> scroll styles if we are sizing the window, when the sizing completes. Basically when we receive the WM_EXITSIZEMOVE message.
> For normal sizing operations we continue to do this in WM_SIZE as before.
> 
> From testing on my thinkpad with Win7, desktop with Win7 and Win8 this works well
> 
> BUG= 334454 ,  334541 
> TBR=sky
> 
> Review URL: https://codereview.chromium.org/133273020

TBR=ananta@chromium.org

Review URL: https://codereview.chromium.org/144403003
------------------------------------------------------------------------
Cc: ashej...@chromium.org
 Issue 336450  has been merged into this issue.
 Issue 336452  has been merged into this issue.
 Issue 336379  has been merged into this issue.
 Issue 336348  has been merged into this issue.
 Issue 336388  has been merged into this issue.
 Issue 336670  has been merged into this issue.
 Issue 336202  has been merged into this issue.
Cc: tkonch...@chromium.org
 Issue 336071  has been merged into this issue.

Comment 36 by dhw@chromium.org, Jan 22 2014

 Issue 334227  has been merged into this issue.

Comment 37 Deleted

This may be fixed, but there's another regression caused by the new select box style which is not fixed. Typing a space to do an incremental search in a select is broken because it now opens the menu instead:

https://code.google.com/p/chromium/issues/detail?id=336856

Comment 39 by rschu...@gorges.us, Jan 22 2014

I'm having this issue in Chrome 32.0.1700.76m under Windows 8.

The example posted (http://enjoysmile.com/content/options.html) does not work properly, when rolling the mouse over the actual text ("8 - No hover") in the last item, it does not highlight; however, if I roll my mouse over that item to the *right* of the actual text, it *does* react.

The error may seem to be periodic, but if you shuffle the mouse vertically over the two last items, it seems more probably that the actual label/text inside the item's box is somehow gobbling the mouse-over event or somehow blocking the event from reaching the actual box.

Comment 40 by igp...@gmail.com, Jan 24 2014

Hi, I am still experiencing both issues (on v.32.0.1700.76 m):
 - 334522:vertical-scroll-bar-stuck-to-the-top & 
 - 334454:no-highlight-on-the-last-itme-in-the-drop-down issues

... BUT both issues now have status 'closed'/'fixed' (?!)

Shall I download sth or wait for the auto-update of Chrome, someone who knows?

yeah me to? It's not fixed for me either

2014/1/24, chromium@googlecode.com <chromium@googlecode.com>:

Comment 42 by omn...@gmail.com, Jan 24 2014

> Hi, I am still experiencing both issues (on v.32.0.1700.76 m):

It's because they think it's fixed as long as it work for them in there Dev builds.

After that they forget about this problem, yet we need to wait n months to get the fix in the stable channel.

When the fix will be released to stable?!!!!!!!! Please give some date, we need to know what to say to the users!
Normally I wouldn't add a "me too"-style comment to this thread, but maybe google is monitoring it. 

This is a ridiculously critical bug that should've never come close to stable release. It easily affects the largest of Chrome's user base.

It not only makes it impossible to use scrollbars in select elements, it makes it impossible to use developer tools which is the only reason why most of us developers work solely in Chrome.

If this bug is indeed fixed, it needs to be shipped IMMEDIATELY!!!!
I gave up and switched back to Firefox and firebug, they obviously aren't
taking quality issues seriously
We have about 60,000 users. Many had the impression that this was our system's fault. We tried to wait, but finally we had no option but to ask them to use Firefox.
Currently seeing this issue which is breaking dropdowns for chrome v30.0.1700 on windows 7.

Comment 47 by tkent@chromium.org, Jan 24 2014

Labels: Restrict-AddIssueComment-EditIssue
The next stable update is going to include the fix.  Please wait for it.

Labels: TE-Verified-M32 TE-Verified-M33 TE-Verified-M34
Tested the issue on Windows8 OS - chrome version 32.0.1700.102 (Official Build 246481) m, 33.0.1750.54 (Official Build 247046) m and 34.0.1807.0 (Official Build 247146) canary. Fix is working as intended. Last element hover is working fine like the other elements.
Labels: TE-Verified-32.0.1700.102

Comment 50 by tkent@chromium.org, Jan 28 2014

 Issue 337424  has been merged into this issue.

Comment 51 by tkent@chromium.org, Jan 28 2014

 Issue 337842  has been merged into this issue.

Comment 52 by tkent@chromium.org, Jan 28 2014

 Issue 338096  has been merged into this issue.

Comment 53 by tkent@chromium.org, Jan 28 2014

 Issue 338584  has been merged into this issue.
 Issue 338640  has been merged into this issue.
 Issue 334227  has been merged into this issue.
 Issue 334227  has been merged into this issue.

Comment 57 by laforge@google.com, Feb 14 2014

 Issue 334227  has been merged into this issue.

Sign in to add a comment