Closed Bug 795648 Opened 9 years ago Closed 9 years ago

Opening a new tab sometimes results in a corrupted tab region

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla19
Tracking Status
firefox18 + verified
firefox19 + verified

People

(Reporter: Dolske, Assigned: mattwoodrow)

References

Details

(Keywords: regression)

Attachments

(5 files, 1 obsolete file)

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.
Attached image Screenshot
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>
I can't reproduce this on linux-x64/basic or win7/d3d10.
Do you have accelerated layers enabled? (about:support -> GPU accelerated windows)
(That question was @dolske, IIUC.)
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.
Attached image 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.
Duplicate of this bug: 801408
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.
QA Contact: anthony.s.hughes
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.
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
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.
(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
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.
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.
Reproduced this again on 19.0a1 (2012-10-30).
Assignee: nobody → matt.woodrow
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.
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.
(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.
I've also seen the bug today on 19.0a1 (2012-11-08) FYI.
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.)
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.
(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
Attached image Whole tab strip
I'm starting to see frequent corruption of the entire tab strip now. :(
(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 !
Sorry, I linked to the wrong bug earlier -- I meant Bug 806661.
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
Attachment #682211 - Flags: review?(joe) → review-
r=joe
Attachment #682211 - Attachment is obsolete: true
Attachment #682514 - Flags: review+
(In reply to Matt Woodrow (:mattwoodrow) from comment #32)
> Created attachment 682514 [details] [diff] [review]
> Fixed patch that landed
> 
> r=joe

h4x
https://hg.mozilla.org/mozilla-central/rev/a15be1ab7b3a
https://hg.mozilla.org/mozilla-central/rev/349c0099e6a7
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
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
Attachment #682514 - Flags: approval-mozilla-aurora?
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.
Attachment #682514 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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
Sorry, I had to post this comment on bug 812602. :-)
Not able to reproduce this on Mac OS 10.8, FF 18b4. Tabs are working as expected.
(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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.