975397 - border-image on element with :visited-dependent styles gives ###!!! ABORT: Should be tracking any image we're going to use!: 'mImageTracked', layout\style \nsStyleStruct.h, line 208

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Carsten Book [:Tomcat]]

found via bughunter on https://itunes.apple.com/br/app/three-little-pigs-by-nosy/id418543664?mt=8&ign-mpt=uo=4

(feel free to open this bug if its not a security issue)

loading this page results in a trunk debug build on win7 with:

[720] ###!!! ABORT: Should be tracking any image we're going to use!: 'mImageTracked', file c:\users\mozilla\debug-builds\mozilla-central\layout\style
\nsStyleStruct.h, line 208

Comment 1

[Carsten Book [:Tomcat]]

Attachment: bughunter stack

Comment 2

[Carsten Book [:Tomcat]]

Attachment: testcase

Comment 3

[Mats Palmgren (inactive)]

Fwiw, the assertion was added in bug 512260 part 3.

Comment 4

[Mats Palmgren (inactive)]

Attachment: stack

Comment 5

[Daniel Veditz [:dveditz]]

dbaron: how bad is this assertion?

Comment 6

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

Oops, bugzilla doesn't let me transfer a needinfo? to somebody else unless I *also* uncheck the checkbox that says I'm answering it.

Comment 7

[Timothy Nikkel (:tnikkel)]

Believe it or not I haven't ever dealt with tracking of CSS images, only img elements and related. So I don't know the answer off the top of my head.

Comment 8

[Timothy Nikkel (:tnikkel)]

After a quick look I would think that if we didn't track an image the worst that could happen is we don't keep around the decoding image, so we have to do more decoding work, maybe we might not draw the image at all in some situations, and if it's an animated image we might not animate it. There could be worse consequences but at the surface that's what I would guess.

Comment 9

[Patrick McManus [:mcmanus]]

I repro this consistently on a new profile accessing http://www.apple.com with  34c6e4261eb036cb6050d5b1a73cd9bc4f5f6251 as my head

Comment 10

[Gregor Wagner [:gwagner]]

I can reproduce this 100% on current trunk on nexus 4:

Go to maps.google.com
Search for Mozilla and click on Mozilla SF office address.

Comment 11

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

Pretty sure this will fix it:
https://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/ba7682624f08/track-image-visited-link
but still need to write a test.

Comment 12

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

Attachment: Call TrackImage when constructing a new nsStyleBorder

I confirmed that the crashtest crashes in the harness without the patch.

Comment 13

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

I'm somewhat curious as to why fuzzers didn't find this until very recently (bug 987015).  Did we only recently start fuzzing in a way that triggered painting?

It doesn't seem like it should be a recent regression, although maybe I'm missing something.  It looks to me like a regression from bug 512260 (August 2010), since bug 147777 was slightly earlier (April 2010).

Comment 14

[Jesse Ruderman]

> I'm somewhat curious as to why fuzzers didn't find this until very recently (bug 987015).

My guess is that https://hg.mozilla.org/mozilla-central/rev/13a5fb1e8525 helped by giving the fuzzer an example of giving the "border-image-source" property a data: image-URL value.  I filed two bugs involving that pattern in the last month.

Comment 15

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/c2d529d8aa2b

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c2d529d8aa2b

Comment 18

[u279076]

I don't think this needs tracking or QA verification. Please correct me if you think I am wrong.

Comment 19

[Benjamin Kerensa [:bkerensa]]

I don't think we need to track this please re-nominate if there is some additional justification.