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

Issue 624162 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Element innerHTML does not update when style with "linear-gradient" properties

Reported by m...@marceli.no, Jun 28 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux i686 (x86_64)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Example URL:
http://stackoverflow.com/q/38086610/1666547

Steps to reproduce the problem:
1. Add element to page with text content "foo".
2. Add the following CSS properties to element:
   background: linear-gradient(#000000,#ffffff);
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
3. Set time out of 500 milliseconds
4. Change text via "Element.innerHTML = 'bar'"

What is the expected behavior?
Element text should visually update to "bar" when the time out expires.

What went wrong?
The element is not updated visually.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? N/A 

Chrome version: 47.0.2526.106  Channel: n/a
OS Version: Ubuntu 16.04 LTS
Flash Version: Shockwave Flash 21.0 r0

This does not seem to be present in the latest version (51) of Chrome. See working hack on the URL posted.
 

Comment 1 by ajha@chromium.org, Jun 29 2016

Cc: e...@chromium.org ajha@chromium.org
Components: Blink
Labels: -Pri-2 -Type-Compat ReleaseBlock-Stable hasbisect M-52 OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: msten...@opera.com
Status: Assigned (was: Unconfirmed)
Able to reproduce this on the latest beta(52.0.2743.49) and the latest M-53(53.0.2782.0) on Windows-7, Mac OS 10.11.5 and Linux Ubuntu 14.04. Works fine on the latest stable(51.0.2704.106).

Regressed in M-52:

Last good build: 52.0.2730.0
First bad build: 52.0.2733.0

Note: There is no intermediate build b/w the above trunk builds.

Changelog:
https://chromium.googlesource.com/chromium/src/+log/a69b588abf1afd1e37e58463a07df4da722ded02..6958c09a512167e272ba30c3d1caeea283a803da

Suspected change: https://codereview.chromium.org/1964083002

Looks like  mstensho@ will be back on 08/08, hence assigning to eae@(reviewer of the CL) for more inputs on this.

eae@: Could you please help in investigating this further and assign to the appropriate owner from the above CL if the suspected change is not related.
** IMPORTANT change in M52 merge date due to first 2 weeks of July no release weeks **

M52 Stable is launching very soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged ASAP. 
All changes MUST be merged into the release branch by 5pm on July 1 to make into the desktop Stable final build cut. 

Thank you!
M52 Stable is launching very soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged ASAP. All changes MUST be merged into the release branch by 5pm on July 8th (in case if you missed today's 5:00 PM PST deadline) to make into the desktop Stable final build cut. Thank you!
Able to reproduce the issue on mac 10.11 chrome version 54.0.2787.0	

mstensho@, Could you please take a look
Cc: msten...@opera.com
Components: -Blink Blink>Paint>Invalidation
Owner: ----
Status: Untriaged (was: Assigned)
Moving back to untraiged as mstensho@ is OOO
Owner: wkorman@chromium.org
Status: Assigned (was: Untriaged)
Assigning it to reviewer for the suspected CL above.

wkorman@, can you please take a look at this issue as this is marked as a stable blocker ?
On Linux 52.0.2743.60, and ToT, with attached test case (following initial bug report description) I am not able to repro. Is the test representative?
624162.html
246 bytes View Download
I tried to repro at r393005 which represents 52.0.2733.0 marked as first bad build above by ajha@ and my test case does not repro. I will try with bisect-builds.py on Monday.
Status: WontFix (was: Assigned)
Closing as no known repro. It's possible there was a bug/typo in the initial comment on repro steps. If reporter can provide feedback on my test case and questions above, please reopen.

Sign in to add a comment