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

Issue 750611 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Text overlaps with search icon in Ebay for chrome extension

Project Member Reported by sc00335...@techmahindra.com, Jul 31 2017

Issue description

Chrome Version:62.0.3172.0
OS:Ubuntu 14.04, Windows

Test URL: https://chrome.google.com/webstore/detail/ebay-for-chrome/khhckppjhonfmcpegdjdibmngahahhck?utm_source=chrome-ntp-icon

What steps will reproduce the problem?
(1)Launch chrome and add above extension
(2)Now click o that extension from browser containment area and give long text and observe

Expected: No overlapping should be seen.
Actual:Instead text overlaps with search icon.

This is a regression issue broken in M61.

Good Build: 61.0.3141.0 dev
Bad Build: 61.0.3142.0 dev
 
Actual_ebay.png
155 KB View Download
Expected_ebay.png
240 KB View Download
Labels: OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reprodcue the issue using #62.0.3172.0 on Mac 10.12.5 as well.

Thanks!!

Labels: -Needs-Bisect hasbisect-per-revision
Owner: chrishtr@chromium.org
Status: Assigned (was: Untriaged)
Using per revision bisect providing bisect results below

Bisect Information:
--------------------
You are probably looking for a change made after 482440 (known good), but no later than 482441 (first known bad).

Change Log URL: 
-----------------
https://chromium.googlesource.com/chromium/src/+log/d654734a905602faa2dd33b7a60f06fd80efcdfb..a348403ddc19ee7bb93c38e6dda500c54d12e9d6

chrishtr@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!!
Labels: ReleaseBlock-Stable
Reduced testcase attached.
test.html
373 bytes View Download
Status: WontFix (was: Assigned)
The issue is that an <input> element's shadow DOM tree contains at its root
a LayoutBlockFlow which does not ScrollOverflow unless composited or focused.
Because it does not scroll overflow, it is not a self-painting layer.
Non-self-painting layers are painted in the same paint order as non-positioned
elements. Self-painting ("stacked") layers are painted as if they are positioned.
Therefore, according to the paint order spec, the order of paint is:

1. Background and border of the LayoutBlockFlow
2. Background and border of the sibling element which has a white background
3. Text below LayoutBlock flow

Steps 1 and 2 are in the background painting phase of the containing stacking context.
Step 3 is in the foreground phase.

Firefox agrees with the above rendering.

So what is happening the extension use-case is that the input element extends beyond
the area visible to the user next to the eBay button. The text appears on top of the button
because the button and the input element are not positioned.

Before my CL, I think the self-painting layer status was mixed up, leading to incorrect
rendering as if the element was positioned.

Working as intended.

Sign in to add a comment