Bug 109020 - input element with placeholder text and width set to 100% on focus causes overflow even after losing focus
Summary: input element with placeholder text and width set to 100% on focus causes ove...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Robert Hogan
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-06 00:15 PST by Masataka Yakura
Modified: 2013-02-20 10:28 PST (History)
9 users (show)

See Also:


Attachments
test case (128 bytes, text/html)
2013-02-06 00:15 PST, Masataka Yakura
no flags Details
Patch (6.54 KB, patch)
2013-02-16 02:56 PST, Robert Hogan
no flags Details | Formatted Diff | Diff
Patch (5.92 KB, patch)
2013-02-18 12:04 PST, Robert Hogan
no flags Details | Formatted Diff | Diff
Patch (6.51 KB, patch)
2013-02-18 12:47 PST, Robert Hogan
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Masataka Yakura 2013-02-06 00:15:10 PST
Created attachment 186775 [details]
test case

Steps to reproduce:
1. open the attachment
2. hit Tab key to focus the input element
3. hit Tab again to move focus out from the input element

Expected results:
there is no horizontal scrollbar.

What happened instead:
there is a horizontal scrollbar.

This neither happens on input elements with no placeholder text (or blank placeholder text) nor textarea elements with or without placeholder text.
Comment 1 Robert Hogan 2013-02-16 02:56:35 PST
Created attachment 188703 [details]
Patch
Comment 2 Darin Adler 2013-02-16 13:29:12 PST
Comment on attachment 188703 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=188703&action=review

> Source/WebCore/rendering/RenderBlock.cpp:1698
> +    if (block->node() && block->node()->toInputElement() && block->node()->toInputElement()->placeholderElement() && block->node()->toInputElement()->placeholderElement()->renderer() == child)
> +        return false;

There has to be some better way of doing this than hard-coding the placeholder. Is a placeholder element really the only place in all of WebKit that we have block child that does not affect layout or size of the parent? Is there a better way to set up the render tree so we don’t need this very-specific hack?
Comment 3 Robert Hogan 2013-02-18 12:04:28 PST
Created attachment 188928 [details]
Patch
Comment 4 Dave Hyatt 2013-02-18 12:15:00 PST
Comment on attachment 188928 [details]
Patch

This seems ok. Other approaches you could take would be to simply recompute overflow if the placeholder box does a relayout. This would be better if the placeholder needs to contribute to overflow and doing this causes it to be wrong. It seems like a bug that the placeholder is getting resized but nobody recomputes overflow?
Comment 5 Robert Hogan 2013-02-18 12:47:55 PST
Created attachment 188931 [details]
Patch
Comment 6 Dave Hyatt 2013-02-18 12:50:46 PST
Comment on attachment 188931 [details]
Patch

r=me
Comment 7 WebKit Review Bot 2013-02-19 14:28:06 PST
Comment on attachment 188931 [details]
Patch

Rejecting attachment 188931 [details] from commit-queue.

New failing tests:
platform/chromium/fast/forms/calendar-picker/calendar-picker-appearance-required.html
Full output: http://queues.webkit.org/results/16621955
Comment 8 WebKit Review Bot 2013-02-20 10:28:46 PST
Comment on attachment 188931 [details]
Patch

Clearing flags on attachment: 188931

Committed r143475: <http://trac.webkit.org/changeset/143475>
Comment 9 WebKit Review Bot 2013-02-20 10:28:49 PST
All reviewed patches have been landed.  Closing bug.