Last Comment Bug 405584 - Canvas.drawImage method is not working
: Canvas.drawImage method is not working
Status: VERIFIED FIXED
: regression, verified1.8.1.11, verified1.8.1.12
Product: Core
Classification: Components
Component: Canvas: 2D (show other bugs)
: 1.8 Branch
: x86 All
: -- major with 11 votes (vote)
: ---
Assigned To: Vladimir Vukicevic [:vlad] [:vladv]
:
: Milan Sreckovic [:milan]
Mentors:
http://developer.mozilla.org/samples/...
: 405648 405694 405728 405930 406146 406482 (view as bug list)
Depends on:
Blocks: 391028 405690
  Show dependency treegraph
 
Reported: 2007-11-26 22:05 PST by kevin han
Modified: 2010-09-17 19:16 PDT (History)
49 users (show)
dveditz: blocking1.8.1.11+
mbeltzner: blocking1.8.1.12+
dveditz: wanted1.8.1.x+
reed: in‑testsuite+
mozillamarcia.knous: in‑litmus+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
reftest (6.73 KB, patch)
2007-11-27 12:32 PST, Martijn Wargers [:mwargers] (not working for Mozilla)
vladimir: review+
Details | Diff | Splinter Review

Description kevin han 2007-11-26 22:05:38 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10

canvas.drawImage is not working in version 2.0.0.10

Please, test following URL. (It is a MDC sample page.)

Test URL : http://developer.mozilla.org/samples/canvas-tutorial/3_1_canvas_drawimage.html


It is display following error message.

"error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: http://developer.mozilla.org/samples/canvas-tutorial/3_1_canvas_drawimage.html :: anonymous :: line 12" data: no]"

Reproducible: Always

Steps to Reproduce:
1. goto "http://developer.mozilla.org/samples/canvas-tutorial/3_1_canvas_drawimage.html"
2. 
3.
Actual Results:  
Image is not displayed and console display error message.

Expected Results:  
Image must be displayed.

I think that ctx.drawImage is problem.
Comment 1 Klaus Reimer 2007-11-27 01:40:28 PST
I can confirm this problem. We are using drawImage alot in our web shop and now in firefox 2.0.0.10 everything is broken while it works fine in 2.0.0.8 and all other browsers (including IE with the excanvas extension). Customers are complaining because their Firefox automatically updated to 2.0.0.10 and now they can no longer order photo prints in our shop. I think this is a very serious problem and I hope it will be fixed immediately in a 2.0.0.11 update.

But I also wonder why Google Maps is still working. I thought they used the Canvas stuff for it...
Comment 2 Klaus Reimer 2007-11-27 01:50:20 PST
Here are some popular example web pages which are no longer working with 2.0.0.10:

  * http://www.abrahamjoffe.com.au/ben/canvascape/textures.htm (The rifle is not drawn with canvas so that's why this part of the game is still working)
  * http://developer.mozilla.org/en/docs/Puzzles_using_Canvas_%28external%29
  * http://developer.mozilla.org/en/docs/Water_Reflection_Effect_%28external%29

Bye the way: I'm using Firefox 2.0.0.10 on Ubuntu Linux 7.10. So it's not a windows-only problem.
Comment 3 Martin Stricker 2007-11-27 03:38:01 PST
Bug also confirmed on Mac OS X (10.4.11). Same error message.
Comment 4 Wolfgang Rosenauer [:wolfiR] 2007-11-27 04:00:03 PST
Have to confirm it myself but according to comments I'm going to confirm it here now.
Comment 5 Matthew Hambly 2007-11-27 04:54:23 PST
Confirming this is occurring in my Firefox extension for users on all platforms.
Comment 6 Arthur 2007-11-27 05:56:06 PST
Possibly caused by bug 391028.
Comment 7 Alexander Sack 2007-11-27 06:34:49 PST
applying the follow up attachment 284556 [details] [diff] [review] in bug 391028 fixes this in 2.0.0.10 for me.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2007-11-27 10:23:10 PST
We should make sure we at least have a regression test for this on trunk...
Comment 9 Daniel Veditz [:dveditz] 2007-11-27 10:49:39 PST
(In reply to comment #1)
> We are using drawImage alot in our web shop and now in firefox 2.0.0.10
> everything is broken while it works fine in 2.0.0.8

What site? Would hate to "fix" this and find out you've got a completely different regression. Is there a link that exhibits the problem?

(In reply to comment #5)
> Confirming this is occurring in my Firefox extension

ditto: what extension, doing what to repro the problem?

(yes, I see that the links in comment 0 are broken but I don't know that your problems are fixed by the same patch unless we can try it)
Comment 10 Chris Lu 2007-11-27 11:41:01 PST
Just some testing info:

We develop FoxSaver extension, which works well on 2.0.0.9 and earlier. But it's having exactly the same error after applying 2.0.0.10

To test this bug, just install FoxSaver, and start it. It should work in 2.0.0.9, and not showing pictures on 2.0.0.10.
Comment 11 Chris Lu 2007-11-27 11:44:01 PST
Another testing info:

Please visit this site:
 http://www.foxsaver.com/public/published/

In 2.0.0.9, there are reflection effects. With 2.0.0.10, no reflection effects.
Comment 12 Matthew Hambly 2007-11-27 11:47:48 PST
(In reply to comment #9)
> 
> (In reply to comment #5)
> > Confirming this is occurring in my Firefox extension
> 
> ditto: what extension, doing what to repro the problem?
> 
It's an extension for a specific website that uses canvas to dynamically create images.

It is reproducible by using the drawImage function anywhere in any page/extension.  Personally I'm getting the source image from a "new Image();" with .src set to a data url, specifically png. 
Comment 13 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-11-27 12:32:43 PST
Created attachment 290440 [details] [diff] [review]
reftest
Comment 14 Reed Loden [:reed] (use needinfo?) 2007-11-27 14:20:32 PST
Reftest has not been checked-in, yet.
Comment 15 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-11-27 14:25:51 PST
I just checked it in.
Comment 16 Phil Ringnalda (:philor) 2007-11-27 15:07:37 PST
*** Bug 405694 has been marked as a duplicate of this bug. ***
Comment 17 Phil Ringnalda (:philor) 2007-11-27 15:08:01 PST
*** Bug 405648 has been marked as a duplicate of this bug. ***
Comment 18 Nick Thomas [:nthomas] 2007-11-27 16:00:23 PST
I've landed attachment 284556 [details] [diff] [review] from bug 391028 on MOZILLA_1_8_BRANCH and GECKO181_20071115_RELBRANCH.
Comment 19 Al Billings [:abillings] 2007-11-27 16:13:22 PST
With a build with the fix, I see that http://www.foxsaver.com/public/published/
works correctly with reflections.
Comment 20 John O'Duinn [:joduinn] (please use "needinfo?" flag) 2007-11-27 16:15:15 PST
You can reproduce this bug by looking at
http://www.foxsaver.com/public/published.

For FF2.0.0.10, this shows the photos fine. However the title and photographer
name are on a plain background, when instead, they should be on a background of
a inverted copy of the lower portion of the photo. 

If you see the plain white background, you have repro'd the bug. 
If you see the inverted photo background, you have verified the fix!
Comment 21 Mike Beltzner [:beltzner, not reading bugmail] 2007-11-27 16:18:16 PST
Another test that should be run before verifying this is installing the Fotofox add-on (https://addons.mozilla.org/en-US/firefox/addon/3945) and ensuring that when you add an image for upload, you see the preview inside the picture frame in the sidebar.
Comment 22 Nick Thomas [:nthomas] 2007-11-27 16:34:28 PST
Builds with the fix are at
  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007-11-27-14-mozilla1.8/
  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007-11-27-15-mozilla1.8/
(linux and windows respectively).

The Mac build crashed in the MozillaAliveTest, investigating.
Comment 23 Samuel Sidler (old account; do not CC) 2007-11-27 17:48:25 PST
*** Bug 405728 has been marked as a duplicate of this bug. ***
Comment 24 Premal 2007-11-28 18:34:05 PST
Any idea when 2.0.0.11 will be released with working canvas tags?
Comment 25 Dave Townsend [:mossop] 2007-11-28 21:31:10 PST
*** Bug 405930 has been marked as a duplicate of this bug. ***
Comment 26 J 2007-11-28 23:10:29 PST
Thanks for the quick fix Martijn.  Sorry I missed the duplicate when I posted 405930.  

I'm likewise curious on a 2.0.0.11 fix date.  We have a lot of effected code with numerous customers on Macs effected.  Issuing a temporary fix would be real ugly for us.  I really don't feel like sending out e-mail to all of them explaining our preferred browser made all the navigation Icons in out Oracle backed web applications break.
Comment 27 Nick Thomas [:nthomas] 2007-11-28 23:32:17 PST
The release of 2.0.0.11 is _tentatively_ scheduled for Friday 30th Nov. If that comes off it'll be the fastest turnaround between Firefox releases to date (ie, it relies on everything in the release process going without a hitch).
Comment 28 Chris Lu 2007-11-29 00:28:10 PST
That's good to know. Having 2 more days doing regression test would be better. 

I am really surprised the canvas part was not even tested before releasing 2.0.0.10. 

I still support FireFox, although I consider this incident really dampen it a lot.
Comment 29 J 2007-11-29 08:33:44 PST
I have to agree with Chris on this.  We develop process management web applications on with Oracle that use Ajax, Ruby on rails and we have gone out of our way to tell our customers that we "strongly" recommend they use Firefox.  We make extensive use of features which really show off firefox in a good light.

This little episode really has egg on our face.

For a couple days we have had an unbearable number of support calls.  I would hope this reinforces the need for someone to put in some serious effort on developing a solid and extensive suite of regression tests.  This should have NEVER gotten into a public release.
Comment 30 Arthur 2007-11-29 10:56:51 PST
reply to comment #29)
> This little episode really has egg on our face.

Yes, this was a rather bad regression. For those with a high profile website it's probably useful to test their pages regularly with the latest nightlies from the stable branch:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/
If there are any regressions cry wolf with a bug report with the keyword "regression" and a "blocking 1.8.1.x?" request.
Comment 31 Chris Lu 2007-11-29 11:17:18 PST
It's hard or unrealistic for small business to QA the nightly releases, especially when we are not aware of the release schedule. Even for sites like Yahoo Email is broken by 2.0.0.10. I guess they are not checking the nightly release either.

What's a more realistic solution is to include this kind of major APIs part of an automated testing. And it should not be a fire-fighting remedy, but a well planned QA strategy.

Now we have the testing data for this API. I hope other APIs will include unit test also.
Comment 32 Arthur 2007-11-29 11:26:41 PST
(In reply to comment #31)
> It's hard or unrealistic for small business to QA the nightly releases,
> especially when we are not aware of the release schedule. Even for sites like
> Yahoo Email is broken by 2.0.0.10. I guess they are not checking the nightly
> release either.

It's just a suggestion for those with a few minutes to spare. Testing the stable nightlies isn't that hard. Once you've installed one you can use the update mechanism to stay current and the stable nightlies are stable enough for everyday surfing.

> What's a more realistic solution is to include this kind of major APIs part of
> an automated testing. And it should not be a fire-fighting remedy, but a well
> planned QA strategy.

Absolutely.
Comment 33 J 2007-11-29 11:34:51 PST
Arthur,

Once again I have to agree with Chris on this. 

We have far more pressing issues as a <25 person company, than making daily checks of the firefox nightlies.  Half of us are working 14-18 hours a day already.

Perhaps there should be a subscription service that sends out e-mail to developers alerting them of update releases 72 hours prior to release.  This gives small and mid sized developers an opportunity to vet their code against a stable  branch nightly.  

This would serve your purposes as well as ours and provides an added benefit of insuring we don't burn cycles over testing.  It would also insure this kind of "embarrassment" is avoided in the future.

J
Comment 34 John O'Duinn [:joduinn] (please use "needinfo?" flag) 2007-11-29 11:42:12 PST
(In reply to comment #31)
> Even for sites like
> Yahoo Email is broken by 2.0.0.10. I guess they are not checking the nightly
> release either.

With FF2.0.0.10 on Mac, we just tried using "new" Yahoo mail, and it seems to
work fine. Can you provide more details on what exactly looks broken, and what
OS you were using? 
Comment 35 Nick Thomas [:nthomas] 2007-11-29 11:46:13 PST
(In reply to comment #33)
> Perhaps there should be a subscription service that sends out e-mail to
> developers alerting them of update releases 72 hours prior to release.  This
> gives small and mid sized developers an opportunity to vet their code against a
> stable  branch nightly.  

Mozilla already does this sort of thing. All the release candidates for security releases are announced through the mozilla.announce-prerelease newsgroup on news.mozilla.org, also available by Google Groups at 
  http://groups.google.com/group/mozilla.announce.prerelease/topics
and also by email via the mozilla-announce-prerelease mailing list at  
  https://lists.mozilla.org/listinfo/announce-prerelease
Alternatively you can you get that info (and more) on the web at 
  http://developer.mozilla.org/devnews/
or even pull the RSS feed from that.

Any problems with Yahoo should be handled in another bug please.
Comment 36 J 2007-11-29 11:49:22 PST
Nick,

Thanks, I've just subscribed.  Didn't know about that.  Very useful.

J
Comment 37 Chris Lu 2007-11-29 12:22:05 PST
Nick, this is also very good to know. Subscribed now. Thanks! Although I found no message for 2.0.0.10 pre-release on the group. I guess it's an "urgent" security patch that can skip ordinary release processes. 

John, Sorry, my memory was wrong and 2.0.0.10 does work with Yahoo new UI. I am using 2.0.0.11pre and 3.0 now on my two computers, and Yahoo email is simply direct me to the "classic" UI. 
Comment 38 John O'Duinn [:joduinn] (please use "needinfo?" flag) 2007-11-29 12:25:42 PST
(In reply to comment #37)
> John, Sorry, my memory was wrong and 2.0.0.10 does work with Yahoo new UI. I am
> using 2.0.0.11pre and 3.0 now on my two computers, and Yahoo email is simply
> direct me to the "classic" UI. 
Phew! :-) Good to hear - thanks for the update.
Comment 39 Al Billings [:abillings] 2007-11-29 12:27:02 PST
There is a bug with Firefox 3 and the new Yahoo UI. That isn't simply a Firefox bug and Yahoo has an update to the e-mail webapp staged that fixes it. I'm not sure on their ETA for shipping it.

We have more automated tests on the trunk that catch problems like the current bug. The issue here, really, is that the same tests are not available on branch. 
Comment 40 Al Billings [:abillings] 2007-11-29 12:34:38 PST
Interested parties can try the 2.0.0.11 release candidate as well:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.11-candidates/rc1/
Comment 41 Daniel Veditz [:dveditz] 2007-11-29 13:29:40 PST
This regression broke the "ChromaTabs" extension as well. Not work-critical or all that popular, but I like it. Might be a handy simple testcase.

Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: chrome://chromatabs/content/chromatabs.js :: anonymous :: line 545"  data: no]
Source File: chrome://chromatabs/content/chromatabs.js
Line: 545
Comment 42 J 2007-11-29 13:30:59 PST
I just ran tests on the mac RC1 using 
    ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.11-candidates/rc1/firefox-2.0.0.11.en-GB.mac.dmg and our issue is resolved in this build.  Good job on a fast fix guys.

J
Comment 43 Daniel Veditz [:dveditz] 2007-11-29 17:50:54 PST
I can confirm the fix on WinXP using the beta-channel build for
  test link in comment 0
  test links in comment 2
  FoxSaver.com page (comment 11)
  FotoFox add-on (comment 21)
  ChromaTabs (comment 41)
Comment 44 Carsten Book [:Tomcat] 2007-11-29 22:40:45 PST
verified fixed 1.8.1.11 using Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/2007112718 Firefox/2.0.0.11 and the various testcases/testsites from this bug. Also per comment #42 and #43

-> adding verified keyword
Comment 45 Matthias Versen [:Matti] 2007-11-30 04:21:47 PST
*** Bug 406146 has been marked as a duplicate of this bug. ***
Comment 46 Marcia Knous [:marcia - use ni] 2007-11-30 10:23:40 PST
Jonathan and others that are interested: Please sign up for our newly created list, https://mail.mozilla.org/listinfo/betatesters if you are interested in getting a heads up about pending releases.  We would love to have you join the list.

(In reply to comment #33)
> Arthur,
> 
> Once again I have to agree with Chris on this. 
> 
> We have far more pressing issues as a <25 person company, than making daily
> checks of the firefox nightlies.  Half of us are working 14-18 hours a day
> already.
> 
> Perhaps there should be a subscription service that sends out e-mail to
> developers alerting them of update releases 72 hours prior to release.  This
> gives small and mid sized developers an opportunity to vet their code against a
> stable  branch nightly.  
> 
> This would serve your purposes as well as ours and provides an added benefit of
> insuring we don't burn cycles over testing.  It would also insure this kind of
> "embarrassment" is avoided in the future.
> 
> J
> 

Comment 47 J 2007-11-30 10:28:44 PST
Marcia Knous,

Thanks Marcia.  That's helpful.

Jonathan
Comment 48 J 2007-12-02 09:44:05 PST
Marcia, Nick, et. al,

I wanted to send you all a note thanking you for your quick response to this issue and especially to Martijn for effecting a fix in just 16 hours that allowed us to get RC nightlies tested quicker that we could have ever hoped.

I know there's been a lot made of this episode.  I have even seen posts from bugzilla used horribly out of context by the online media, but in our book the response to this was absolutely stellar.  As developers ourselves we recognize that from time to time you are bound to introduce bugs like this.  Anyone who claims that their company is procedurally immune from this kind of thing is completely delusional.

This, in our book, is a bright example of why open source development of this sort is working.  I could never have imagined a closed source vendor responding to a critical fix with an actual release in +/- 48 hours.

Rest assured you will continue to have our support and we look forward to continuing our users to use Firefox as their primary browser.

J
Comment 49 Jesse Ruderman 2007-12-02 16:38:25 PST
*** Bug 406482 has been marked as a duplicate of this bug. ***
Comment 50 John O'Duinn [:joduinn] (please use "needinfo?" flag) 2007-12-19 09:34:07 PST
I wanted to comment on something that came up a few times in discussions above. Paraphrasing, the question was:

"Can you let us know a few days before shipping, when a new FF is coming, so we can test it and confirm it doesn't break with our site - *before* you ship FF"?



Well, actually, we already do this. Let me explain with some background...

We have 3 different channels for sending out updates to users. These channels are currently called: nightly channel, beta channel and release channel. The nightly channel was discussed above, keeping you updated with new nightly builds as they are produced - the "bleeding edge" of browser development, so to speak, and typically of most interest to FF developers and testers. However, I'd like to talk more about the "beta" and "release" channels.

As part of our release process, after we finish our in-house testing, we make the new FF release candidate available to "beta" channel users.
* If there are showstopper bugs reported by "beta" channel users, we stop the release, fix the bugs, generate a new release candidate and push that new release candidate out to "beta" channel users. Repeat as needed. Most releases ship on rc1, but looking back over all the releases in the last 7 months, we've had a couple of rc2s and one rc3.
* If there are no showstoppers reported by "beta" channel users after 3-7 days of exposure, we take the *same* identical bits that are on "beta" channel and copy them out to "release" channel users. The "beta" channel and "release" channel users then remain identical, until we start shipping the next release, when we repeat the above process all over again.

The important point here is, for most of the time, people on the "beta" channel have exactly the same bits as people on the "release" channel. The only exception is when Mozilla is about to ship a new release - thats when users on the "beta" channel will be *newer* than the "release" channel, using what *will* soon be available on the "release" channel. For people who dont want to risk instability of the nightly builds, yet at the same time, care about ensuring new upcoming FF releases work for them without any surprises, this "beta" channel is the place to be.


How do you get onto the "beta" channel? There's 3 different ways:

1) Download and install a beta version of FF from ftp.mozilla.org. Once that beta version of FF is running, it will automatically monitor the "beta" channel for new release candidates, and refresh forward to the latest release candidate when available. For example, if you were do this today, you would download and install FF2.0beta from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/2.0b2. Once installed, use CheckForUpdates to update from FF2.0b2 to the FF2.0.0.11release candidate. This FF2.0.0.11 release candidate is identical to the "release" FF2.0.0.11.  Now, just use your FF2.0.0.11 install like normal. At some point in the future, whenever Mozilla start producing release candidates for FF2.0.0.12, your FF2.0.0.11 "beta" browser will automatically refresh forward to the new FF2.0.0.12 release candidate - in the same way that a regular release version of the browser refreshes forward to newer releases, except that this would happen a few days *before* we officially release FF2.0.0.12. (As usual, instead of FF automatically updating, you could configure FF to notify you of newly available updates before updating. This is controlled by your settings in Options -> Advanced -> Update -> When Updates are found.)

2) Install the "Update Channel Selector" addon into your browser,which allows you to change channels by picking from a popdown menu, and then using CheckForUpdates to install the latest updates from whatever channel you choose. See details at http://www.oxymoronical.com/web/firefox/updatechannel.

3) Monitor new release candidate announcement details in newsgroups, email lists, discussion forms and on Mozilla websites. Once notified of an upcoming release, you can manually download and install the release candidate.

#1 allows slightly less control, always updating the one FF installation as updates become available, but it also the easiest for ongoing effort - everything just happens automatically. #3 allows you the most control, but also takes the most ongoing manual effort. #2 is somewhere in between. For my usage, I prefer to use #1 approach, but all these approaches will work, so its a matter of personal preference.


Sorry for the long post, but hopefully the background details help.

Comment 51 Al Billings [:abillings] 2008-01-22 16:33:59 PST
Verified again in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12pre) Gecko/2008012208 BonEcho/2.0.0.12pre.
Comment 52 Biju 2008-01-29 04:10:29 PST
please check whether bug 414539 is related 
Comment 53 Marcia Knous [:marcia - use ni] 2008-03-26 17:40:14 PDT
https://litmus.mozilla.org/show_test.cgi?id=5226 has been added to Litmus to address this case, both branch and trunk.

Note You need to log in before you can comment on or make changes to this bug.