1269202 - Abspos search icon is mispositioned, on mobile view of wix.com support page

Status: NEW

(Core :: Layout: Positioned, defect, P4)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Visit https://www.wix.com/support/html5/
 2. Enter "Responsive Design Mode" (or reduce the window size to be ~phone sized) so that the page enters the mobile view.
 3. Look for the blue search button. (with a "magnifying glass" icon)

EXPECTED RESULTS:
Blue search button should be in search textfield.

ACTUAL RESULTS:
Blue search button is at upper-right, partly clipped. (Nowhere near textfield.)


From a bit of poking around in devtools, it looks like this icon is absolutely positioned (and also has a negative "margin-top" applied), and its abspos container is an <a> element with position:relative which wraps the search box & the search button.


Edge 13 and Chrome 51 each give EXPECTED RESULTS.
Firefox Nightly 49.0a1 (2016-04-29) as well as release (46) give ACTUAL RESULTS.

Comment 1

[Daniel Holbert [:dholbert]]

(I initially filed this as a mobile-webcompat issue at https://github.com/webcompat/web-bugs/issues/2504 , but now I'm suspecting it's a Gecko bug.)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot

Comment 3

[Daniel Holbert [:dholbert]]

> ACTUAL RESULTS:
> Blue search button is at upper-right, partly clipped. (Nowhere near textfield.)

(Sorry -- the icon is not actually clipped in the screenshot I just attached, but it is clipped on Android. Anyway, the positioning is the main issue here; not the clipping.)

Comment 4

[Mats Palmgren (inactive)]

Attachment: standalone testcase

It seems the root cause for the difference to Chrome is that the
div.hero-titles element is a float, so I suspect the placeholder
for the abs.pos. ends up after it on that line in Firefox.

Adding .search-box {clear:both} makes it display the same as Chrome.

I think this has been reported before; not sure if this is really
a bug per spec though, so it might have been resolved as invalid.

Comment 5

[Mats Palmgren (inactive)]

Might be a dupe of bug 997189.

Comment 6

[Daniel Holbert [:dholbert]]

Updates:
 (1) Wix applied the suggested workaround from comment 4 (clear:both), which fixed the main/original issue here (on their end). Given the end of comment 4, it sounds like perhaps that was the best way to address this.  We do still have the testcase here, though, if our behavior here was indeed buggy.

 (2) There's one independent incremental-layout issue revealed by this same Wix page & by a modified version of Mats' reduced testcase -- I filed bug 1270579 on that.