684672 - smearing (incorrect invalidation) when element with background-color and background-clip:content-box is resized

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[bugzilla33]

Attachment: barcode.html

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; .NET4.0E; FDM; Tablet PC 2.0; MS-RTC LM 8)

Steps to reproduce:

1. Run testcase
2. Click TEST button
3. smeared pixels when elements with background-color are moved around
4. other browsers (IE, Chrome, Safari, Opera) do not smear pixels


Actual results:


'barcode' efect



Expected results:


continuous bar

Comment 1

[bugzilla33]

Attachment: testcase

Comment 2

[bugzilla33]

Attachment: testcase

Comment 3

[bugzilla33]

There is a problem with setting text/html for testcase. Please use the URL.

Comment 4

[Alice0775 White]

Works:
http://hg.mozilla.org/mozilla-central/rev/e5dd52dd3cb5
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100608 Minefield/3.7a5pre ID:20100608190249
Fails:
http://hg.mozilla.org/mozilla-central/rev/f17c85b40f0f
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100608 Minefield/3.7a5pre ID:20100608214125
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e5dd52dd3cb5&tochange=f17c85b40f0f

Triggered by
Bug 549809 - Rename background-origin and background-clip properties and values to match css3-background

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That regression range seems incorrect.  You should add '-moz-background-origin: content' to the testcase (in addition to background-origin: content-box) to find a real regression range.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That said, I think the underlying problem is relatively clear:  our invalidation rules:
 (1) invalidate the difference between old and new areas
 (2) invalidate the whole box if the background is position-dependent
don't work correctly with background-clip.  I'm not quite sure what we ought to do here, though.

I see the problem on Linux as well.

Comment 7

[Alice0775 White]

(In reply to David Baron [:dbaron] from comment #5)
>  You should add
> '-moz-background-origin: content' to the testcase (in addition to
> background-origin: content-box) to find a real regression range.
I added both to second DIV.
  <div style="width:0"><div style="background:black;height:200px;padding-right:1px;background-clip:content;-box-moz-background-origin: content;background-origin: content-box;"></div></div>

I cannot reproduce the problem anymore...
What is wrong?

Comment 8

[Alice0775 White]

oops. pls ignore comment #7

Comment 9

[Alice0775 White]

Attachment: modifiled as copmment #5

(In reply to David Baron [:dbaron] from comment #5)
> That regression range seems incorrect.  You should add
> '-moz-background-origin: content' to the testcase (in addition to
> background-origin: content-box) to find a real regression range.

I got same regression range as comment #4

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to David Baron [:dbaron] from comment #6)
> That said, I think the underlying problem is relatively clear:  our
> invalidation rules:
>  (1) invalidate the difference between old and new areas
>  (2) invalidate the whole box if the background is position-dependent
> don't work correctly with background-clip.  I'm not quite sure what we ought
> to do here, though.

I think we can just invalidate the whole box if the background-clip is not border-box.

Comment 11

[Marcela (Please NI request to Brindusa Tot)]

Hi,
I was not able to reproduce this issue on latest Nightly version 95.0a1 (3032-10-05)(64-bit) on Windows 10 using the test case attached.
Since this seems to be an outdated issue, I'll close it as Resolved - WFM.
Thanks!