[Webkit-unassigned] [Bug 175067] [GTK] Number generator from random.org displays incorrectly hiding the result

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=175067

Adrian Perez <aperez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aperez at igalia.com

--- Comment #3 from Adrian Perez <aperez at igalia.com> ---
(In reply to Carlos Alberto Lopez Perez from comment #2)
> And the thing is that I don't know how we can fix this.
> 
> I already felt that overriding the size of the input numbers that was choose
> by the web designer was maybe going to cause some issues on some sites when
> I proposed that solution, but I don't know how to fix this issue without
> doing that.
> 
> The only sane thing I thing we can do is to go back to the spin buttons that
> we had some years ago:
> 
> Now we have this:
> https://trac.webkit.org/export/217674/webkit/trunk/LayoutTests/platform/gtk/
> fast/forms/number/number-appearance-spinbutton-layer-expected.png
> 
> Before we had this:
> https://trac.webkit.org/export/148821/webkit/trunk/LayoutTests/platform/gtk/
> fast/forms/number/number-appearance-spinbutton-layer-expected.png
> 
> 
> Web designers are going to keep testing their sites only with
> chrome/firefox/safari, and all of this browsers have small spinbuttons likes
> the ones we had before. Either we go back to small spinbuttons or we will
> breaking some sites like this one.

Would it be an acceptable tradeoff to use the current (new, bigger buttons)
version when the size of the field is wider than a certain threshold, and
use the other version (old, narrow buttons) for the narrow inputs? I am aware
that doing it that way makes us maintain two different ways for rendering the
inputs, but at least it wouldn't break any website, while still trying to
provide the version with the easier-to-hit button when possible.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170802/4e14791c/attachment.html>