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

Issue 625604 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Use other robhogan account instead.
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Search icon is overlapped with some characters in www.wordnik.com site

Project Member Reported by susanjun...@techmahindra.com, Jul 4 2016

Issue description

Version: 54.0.2787.0
OS: Ubuntu 14.04, Windows

URL : https://www.wordnik.com/login

What steps will reproduce the problem?
(1)Launch Chrome and go to the above URL.
(2)Observe the search icon which is inside the search text box.(please refer screen shot)

Expected: No overlapping should be seen between characters and search icon.

Actual: Instead overlapping is seen.

This is a Regression issue broken in M-41.

Manual good and Bad Builds:
Good build: 41.0.2244.0
Bad build: 41.0.2245.0

Below is the Bisect info :

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/534556c128a9624c3c536957ebf76bffd5f962bb..f4a661219de158fa7c6e1cc5a82770ccdf8548c2


BLINK CHANGELOG URL: 
https://chromium.googlesource.com/chromium/blink/+log/71d0c65..dd85771

Suspecting https://chromium.googlesource.com/chromium/blink/+/94a5b88aded99c887831975c6dc6be7104039369  from above Changelog and blink log

@robhogan: Please feel free to re-assign if its not related to your change

 
Actual_search.png
146 KB View Download
Expected_search.png
150 KB View Download
Labels: -OS-Mac

Comment 2 by ajha@chromium.org, Jul 4 2016

Components: Blink
Labels: OS-Mac
Able to reproduce this on the latest canary(54.0.2787.0) on Mac OS 10.11.5 as well.
Components: -UI -Blink Blink>Paint
Not really sure what label to use here... paint folks, redirect if needed :)
Reduction:

<!DOCTYPE html>
<p> crbug.com/625604 : Displays fallback content because value is null. Firefox displays nothing below.</p>
<input value="" type="image" style="background-image: url('data:image/gif;base64,R0lGODdhAgACAIABAAAAAP///ywAAAAAAgACAAACA0QCBQA7'); display: block;">
<input value="" type="image" style="display: block;">

We display the 'submit' text on input elements with type image when value is "". Presto does the same. FF does not.
625604.html
298 bytes View Download
Components: -Blink>Paint Blink>Layout
Status: Unconfirmed (was: Assigned)
So we treat value="" and the absence of the value attribute as the same on form controls. 

Comment 6 by e...@chromium.org, Jul 6 2016

Components: -Blink>Layout Blink>Forms

Comment 7 by tkent@chromium.org, Jul 8 2016

Status: Assigned (was: Unconfirmed)
Project Member

Comment 8 by bugdroid1@chromium.org, Jul 9 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/350b1fecbdea7310b122e3e83c67929fa282d754

commit 350b1fecbdea7310b122e3e83c67929fa282d754
Author: robhogan <robhogan@gmail.com>
Date: Sat Jul 09 22:14:36 2016

Don't treat an empty value attribute as null on image input types

If value="" is specified on an image-type form control then use "" as the alt-text
for the control if one is required. This matches Firefox and Edge, also IE11.

BUG= 625604 

Review-Url: https://codereview.chromium.org/2127093004
Cr-Commit-Position: refs/heads/master@{#404571}

[add] https://crrev.com/350b1fecbdea7310b122e3e83c67929fa282d754/third_party/WebKit/LayoutTests/fast/forms/input-image-button-with-empty-value-expected.html
[add] https://crrev.com/350b1fecbdea7310b122e3e83c67929fa282d754/third_party/WebKit/LayoutTests/fast/forms/input-image-button-with-empty-value.html
[modify] https://crrev.com/350b1fecbdea7310b122e3e83c67929fa282d754/third_party/WebKit/Source/core/html/HTMLInputElement.cpp

Comment 9 by tkent@chromium.org, Jul 22 2016

Status: Fixed (was: Assigned)

Sign in to add a comment