795648 - Opening a new tab sometimes results in a corrupted tab region

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Justin Dolske [:Dolske]]

Easiest to explain with a screenshot. Started with 9/29 OSX nightly, so I'll make an uneducated guess that DLBI is at fault.

Happens maybe 10% of the time when opening a new tab. Noticed it opening image links on Reddit. Sometimes fixes itself in a fraction of a second, sometimes lingers for multiple seconds.

A little bothersome is that the garbled content has pixels I won't expect to see from this region, so I wonder if there's some uninit'd memory being read.

Comment 1

[Justin Dolske [:Dolske]]

Attachment: Screenshot

Comment 2

[Justin Dolske [:Dolske]]

Interesting, I can easily trigger it maybe 50%+ of the time with a direct link to an image, but for other links it's OK. Maybe something to do with the rapid display/removal of the throbber, or the tab finishing loading before the tab-grow animation is complete? </wild guesses>

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I can't reproduce this on linux-x64/basic or win7/d3d10.

Comment 4

[Matt Woodrow (:mattwoodrow)]

Do you have accelerated layers enabled? (about:support -> GPU accelerated windows)

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(That question was @dolske, IIUC.)

Comment 6

[Justin Dolske [:Dolske]]

Y(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> Do you have accelerated layers enabled? (about:support -> GPU accelerated
> windows)

Yes. I'm on new Mac hardware with OS X 10.8.

Comment 7

[Alex]

Attachment: Page/tab corruption

I've seen the tab corruption a few times, but this is the first time I've seen the corruption spread to other regions.

I think I got this by quickly opening an image and switching tabs, but since I wasn't expecting it I didn't really pay attention to the exact steps involved.

Comment 10

[Benoit Girard (:BenWa)]

As I noted in bug 801408 by opening the following image in a new tab the icon becomes corrupted when by triggering several mouse over events:
http://i.imgur.com/qHQW1.jpg

I can reproduce this with and without OGL layers on 10.7. I believe this may be related to this issue.

Comment 11

[u279076]

Reproduces for me in today's 18.0a2 Aurora but not the 2012-09-29 18.0a1 Nightly as indicated in comment 0. I'll try to find a more narrow regression window.

Comment 12

[u279076]

I've narrowed this down to between 2012-09-28 and 2012-09-29 18.0a1 Nightly.

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=895f66c4eada&tochange=85f561c755f6

Comment 13

[Benoit Girard (:BenWa)]

Is it possible to narrow it down a bit further using the FTP builds? There's a ton of changes for that day and I don't see any progressive drawing patches on there.

Comment 14

[u279076]

(In reply to Benoit Girard (:BenWa) from comment #13)
> Is it possible to narrow it down a bit further using the FTP builds? There's
> a ton of changes for that day and I don't see any progressive drawing
> patches on there.

Yup, on it...

Using the tinderbox builds on FTP I was able to regress this further down to the following changeset. Unfortunately, that points to a single 81 change PGO merge. I can't narrow this down further without pulling and building individual changesets.

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b274e8e3479f&tochange=b62b229a4d41

Comment 15

[Benoit Girard (:BenWa)]

You actually can get builds from mozilla-inbound here:
ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/

But watch out since I think they show up in the order they finish building+uploading, not by landing date.

Comment 16

[Matt Woodrow (:mattwoodrow)]

That regression range includes the entirety of DLBI (Bug 539356), which this bug is already marked blocking.

If it's fixed on nightly, then finding the changeset that fixed it would be good so we can uplift that to aurora.

Comment 17

[Benoit Girard (:BenWa)]

Reproduced this again on 19.0a1 (2012-10-30).

Comment 18

[Tim Martin]

I've been seeing this bug for a while, like others mostly when opening images from reddit.

But in the last day or so, I noticed that the link text on the original page will *also* get corrupted in the same way.  I'll try to upload a screenshot if I catch it again.

Comment 19

[u279076]

Tim, can you please check if this reproduces for you on the latest Nightly? I think that would help narrow down if this was ever fixed.

Comment 20

[u279076]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #19)
> Tim, can you please check if this reproduces for you on the latest Nightly?
> I think that would help narrow down if this was ever fixed.

Actually, nevermind. Comment 17 seems to indicate this has not been fixed on Nightly. I'm not sure adding *another* screenshot of the issue will assist Matt in fixing this bug.

Comment 21

[Benoit Girard (:BenWa)]

I've also seen the bug today on 19.0a1 (2012-11-08) FYI.

Comment 22

[Tim Martin]

Sorry, I thought that the page corruption might be an aspect of this bug that hadn't been mentioned.  (The pattern I saw didn't match the screenshot posted.)

But actually, I'm seeing all sorts of graphical glitches in todays build, so it's probably something distinct.  (Maybe Bug 80661, though that bug is older and I hadn't noticed such page glitchiness until more recently.)

Comment 23

[u279076]

No, I think you are seeing this same bug, just on the content area of the browser window (not restricted to the tab bar). I think the first step should be getting *this* issue fixed and seeing if that fixes what you are seeing. If it doesn't then follow-up bug(s) would need to be filed.

Comment 24

[bhavana bajaj [:bajaj]]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #23)
> No, I think you are seeing this same bug, just on the content area of the
> browser window (not restricted to the tab bar). I think the first step
> should be getting *this* issue fixed and seeing if that fixes what you are
> seeing. If it doesn't then follow-up bug(s) would need to be filed.

Anthony, are you still able to reproduce this on Aurora at this time ? How common is the occurrence of the corruption ? Trying to see if we can nail this down to something specific here which can help Matt take a look

Comment 25

[Justin Dolske [:Dolske]]

Attachment: Whole tab strip

I'm starting to see frequent corruption of the entire tab strip now. :(

Comment 26

[bhavana bajaj [:bajaj]]

(In reply to Justin Dolske [:Dolske] from comment #25)
> Created attachment 680416 [details]
> Whole tab strip
> 
> I'm starting to see frequent corruption of the entire tab strip now. :(

:Dolske are you seeing this on aurora/nightly ? Any STR here will really help us here if you are able to reproduce it often. Thanks !

Comment 27

[Tim Martin]

Sorry, I linked to the wrong bug earlier -- I meant Bug 806661.

Comment 28

[Matt Woodrow (:mattwoodrow)]

Attachment: Debugging patch to help catch this

Comment 29

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't synchronously decode images during painting

Comment 30

[Joe Drew (not getting mail)]

Comment on attachment 682211 [details] [diff] [review]
Don't synchronously decode images during painting

Review of attachment 682211 [details] [diff] [review]:
-----------------------------------------------------------------

::: image/src/RasterImage.cpp
@@ +1078,5 @@
>  already_AddRefed<layers::Image>
>  RasterImage::GetCurrentImage()
>  {
>    nsRefPtr<gfxASurface> imageSurface;
> +  nsresult rv = GetFrame(FRAME_CURRENT, FLAG_NONE, getter_AddRefs(imageSurface));

This calls StartDecoding() unfortunately, which can in fact finish decoding synchronously if you're particularly unlucky.

You should probably add an early exit like so:

if (!mDecoded) {
  RequestDecode();
  return nullptr;
}

@@ +1114,5 @@
>      *_retval = mImageContainer;
>      NS_ADDREF(*_retval);
>      return NS_OK;
>    }
>    

can you also remove this whitespace

Comment 31

[Matt Woodrow (:mattwoodrow)]

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

Comment 32

[Matt Woodrow (:mattwoodrow)]

Attachment: Fixed patch that landed

r=joe

Comment 33

[Joe Drew (not getting mail)]

(In reply to Matt Woodrow (:mattwoodrow) from comment #32)
> Created attachment 682514 [details] [diff] [review]
> Fixed patch that landed
> 
> r=joe

h4x

Comment 34

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/349c0099e6a7

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a15be1ab7b3a
https://hg.mozilla.org/mozilla-central/rev/349c0099e6a7

Comment 36

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 682514 [details] [diff] [review]
Fixed patch that landed

[Approval Request Comment]
Bug caused by (feature/regressing bug #): DLBI
User impact if declined: Random corruption of layers
Testing completed (on m-c, etc.): Been on m-c for a few days
Risk to taking this patch (and alternatives if risky): Low risk, just falls back to the old code if the image isn't decoded yet.
String or UUID changes made by this patch: None

Comment 37

[Alex Keybl [:akeybl]]

Comment on attachment 682514 [details] [diff] [review]
Fixed patch that landed

[Triage Comment]
Approving for FF18 since this is a new DLBI regression that hasn't yet hit the release population, and has a low risk fix.

If this is landed on mozilla-aurora before ~11AM PT tomorrow, this will make the merge from Aurora 18 to Beta 18. If landed 11AM-5PM PT tomorrow on mozilla-beta, it will make the first FF18 Beta. If landed after that, it will end up in the second FF18 beta.

Comment 38

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/edc2aedfaed5

Comment 39

[Koosha KM]

gcc cannot compile this change:

make[4]: Entering directory `/home/koosha/firefox-src/obj-i686-pc-linux-gnu/image/src'
/usr/bin/ccache c++ -o RasterImage.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include /home/koosha/firefox-src/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DSTATIC_EXPORTABLE_JS_API -DNO_NSPR_10_SUPPORT -DEXCLUDE_SKIA_DEPENDENCIES  -DOS_POSIX=1 -DOS_LINUX=1  -I/home/koosha/firefox-src/image/decoders -I/home/koosha/firefox-src/content/svg/content/src -I/home/koosha/firefox-src/content/base/src  -I/home/koosha/firefox-src/layout/svg -I/home/koosha/firefox-src/ipc/chromium/src -I/home/koosha/firefox-src/ipc/glue -I../../ipc/ipdl/_ipdlheaders  -I/home/koosha/firefox-src/image/src -I. -I../../dist/include  -I/home/koosha/firefox-src/obj-i686-pc-linux-gnu/dist/include/nspr -I/home/koosha/firefox-src/obj-i686-pc-linux-gnu/dist/include/nss      -fPIC  -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -Wno-long-long -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -g -Os -freorder-blocks  -fomit-frame-pointer  -I/home/koosha/firefox-src/obj-i686-pc-linux-gnu/dist/include/cairo    -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/RasterImage.o.pp  /home/koosha/firefox-src/image/src/RasterImage.cpp
/home/koosha/firefox-src/image/src/RasterImage.cpp: In member function ‘nsresult mozilla::image::RasterImage::InitDecoder(bool)’:
/home/koosha/firefox-src/image/src/RasterImage.cpp:2528: error: ‘mozilla::image::Decoder::DecodeStyle’ is not a class or namespace
/home/koosha/firefox-src/image/src/RasterImage.cpp:2529: error: ‘mozilla::image::Decoder::DecodeStyle’ is not a class or namespace

Comment 40

[Koosha KM]

Sorry, I had to post this comment on bug 812602. :-)

Comment 41

[Mihai Morar, (:MihaiMorar)]

Not able to reproduce this on Mac OS 10.8, FF 18b4. Tabs are working as expected.

Comment 42

[u279076]

(In reply to MarioMi from comment #41)
> Not able to reproduce this on Mac OS 10.8, FF 18b4. Tabs are working as
> expected.

Thanks Mario. I can also confirm this is no longer reproducible for me with 18.0b4, 19.0a2 2012-12-18, and 20.0a1 2012-12-18.