Last Comment Bug 787623 - mousemove event fails to draw content on canvas
: mousemove event fails to draw content on canvas
Status: VERIFIED FIXED
: regression, verifyme
Product: Core
Classification: Components
Component: Canvas: 2D (show other bugs)
: 15 Branch
: x86 Windows XP
: -- major with 3 votes (vote)
: mozilla18
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
: Simona B [:simonab]
Mentors:
http://software.hixie.ch/utilities/js...
Depends on:
Blocks: 773097 787892
  Show dependency treegraph
 
Reported: 2012-09-01 00:26 PDT by Akash
Modified: 2012-10-19 08:27 PDT (History)
18 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
affected
+
verified
verified


Attachments
test.html (744 bytes, text/html)
2012-09-01 00:26 PDT, Akash
no flags Details
fix (5.44 KB, patch)
2012-09-03 16:49 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
joe: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
lukasblakk+bugs: approval‑mozilla‑beta+
Details | Diff | Review

Description Akash 2012-09-01 00:26:32 PDT
Created attachment 657538 [details]
test.html

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">

<head profile="http://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

    <script>
    var context;
      window.onload = function() {
        var canvas = document.getElementById("myCanvas");
         context = canvas.getContext("2d");

        // do stuff here
      };
 function drawline()
  { 
        context.beginPath();
        context.moveTo(100, 150);
        context.lineTo(450, 50);
        context.stroke();
        console.log("done");

  }
    </script>
  </head>
  <body>
    <canvas id="myCanvas" onmousemove="drawline()" width="578" height="200"></canvas>
  </body>
</html>



Actual results:

The mousemove event fails to draw the content on canvas, it works fine on other browsers such as Google chorme, Opera


Expected results:

Moving the mouse of the canvas should draw a line
Comment 1 :Ms2ger 2012-09-01 00:34:16 PDT
Making it onmousemove="window.drawline()" works... Not sure what's messing us up here.
Comment 2 Akash 2012-09-01 00:56:39 PDT
Can be observed here http://jsfiddle.net/bV54P/2/
Comment 3 Loic 2012-09-01 06:17:25 PDT
Your attached testcase works for me.
Comment 5 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2012-09-01 10:49:24 PDT
Something to do with invalidation? On linux I need to force repaint to see the line.
Comment 6 Akash 2012-09-01 10:54:12 PDT
not really sure whats wrong, facing the same issue on Ubuntu 12 with Firefox 15 installed !!
Comment 7 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2012-09-01 10:57:08 PDT
We need the regression range here.
http://harthur.github.com/mozregression/ should be useful tool.
Comment 8 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2012-09-01 10:58:07 PDT
Or just download various builds to narrow down the range when the behavior changed.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
Comment 9 Akash 2012-09-01 11:00:56 PDT
It worked fine in Firefox 14 tough
Comment 10 Akash 2012-09-01 11:03:30 PDT
and also worked fine the all the versions < 15, had built a application that used the same method that broke when Firefox auto updated to v15
Comment 11 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2012-09-01 11:09:03 PDT
Akash, if you have time, would be great if you could test which nightly build is the first one which
has this problem.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
Comment 12 Akash 2012-09-01 11:51:30 PDT
Sure, just tried the nightly builds from 2012-08-01 (all of them seem to work fine!!)

$ mozregression --good=2012-08-01

Downloading nightly from 2012-08-17

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good

Downloading nightly from 2012-08-25

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good

Downloading nightly from 2012-08-29

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good

Downloading nightly from 2012-08-31

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good

Downloading nightly from 2012-09-01

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good


Last good nightly: 2012-09-01
First bad nightly: 2012-09-02

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-09-01&enddate=2012-09-02

do you want to bisect further by fetching the repository and building? (y or n)


All the above builds seem to work fine
Comment 13 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2012-09-01 12:54:43 PDT
Firefox 15 was in Nightly 12+ weeks ago.
Comment 14 Loic 2012-09-01 13:07:44 PDT
FF15 nightly builds started in late April.

Run something like:
mozregression --good=2012-04-24
Comment 15 Akash 2012-09-01 22:13:34 PDT
Retried the mozregression tool from 2012-04-24, but they seem to work fine. Is the mozregression tool missing some versions?


$ mozregression --good=2012-04-24

Downloading nightly from 2012-06-28

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good

Downloading nightly from 2012-07-31

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good

Downloading nightly from 2012-08-16

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good

Downloading nightly from 2012-08-24

Starting nightly

Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): exit
Newest known good nightly: 2012-08-16
Oldest known bad nightly: 2012-09-02
Comment 16 Loic 2012-09-02 00:25:10 PDT
N(In reply to Akash from comment #15)
> Retried the mozregression tool from 2012-04-24, but they seem to work fine.
> Is the mozregression tool missing some versions?

No, mozreg uses dichotomy to find the regression range between the date of the good version and the date of the bad version when your run mozregression --good=D1 --bad=D2, so that's why it skips some versions, there is no need to test all of them.

In your case, if you postulate the current nightly (FF18) is bad, and the last nightly of FF14 is good, you have to run:
mozregression good=2012-04-24 bad=2012-09-01
Comment 17 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-09-02 21:28:23 PDT
The testcase seems to work OK for me on Windows 7 with and without acceleration disabled. We need to narrow down what causes this bug to appear.
Comment 18 Alice0775 White 2012-09-02 22:24:29 PDT
I can only reproduce without HWA in Firefox15 and Firefox16Beta.
I cannnot not produce in Ayrora17.a2 and Nightly18.a1 with/without HWA.

Regression range(Beta channel)
Good:
http://hg.mozilla.org/releases/mozilla-beta/rev/791245980a6e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0 ID:20120808131812
Bad:
http://hg.mozilla.org/releases/mozilla-beta/rev/5b309ad1a88a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0 ID:20120814224555
Pushlog:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=791245980a6e&tochange=5b309ad1a88a


Regression range(Aurora channel)
Good:
http://hg.mozilla.org/releases/mozilla-aurora/rev/4cbf6aa4f022
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120813 Firefox/16.0 ID:20120814111602
Bad:
http://hg.mozilla.org/releases/mozilla-aurora/rev/c2d5393d005c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120814 Firefox/16.0 ID:20120814123301
Pushlog:
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=4cbf6aa4f022&tochange=c2d5393d005c

Suspected : Bug 773097
Comment 19 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-09-03 01:10:55 PDT
Thanks a ton Alice!

I bet the problem is that with the patch from bug 773097, in this testcase the event triggers drawing into the canvas, but we only do an empty transaction to update the window since nothing else needs to be painted, so we keep not having a layer for the canvas. And this is fixed on trunk because we switched non-HWA canvas to Azure there.
Comment 20 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-09-03 16:42:29 PDT
This might interest you, KFT.

My guess in comment #19 was wrong. The problem seems to be that we call Redraw when there is no canvas surface, which sets mIsEntireFrameInvalid. We paint the window, which would normally clear mIsEntireFrameInvalid, but in this case it doesn't because we bail out of BuildLayer early due to having no surface. So mIsEntireFrameInvalid is still set, so when script actually draws into the canvas, no new invalidate is dispatched.
Comment 21 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-09-03 16:49:44 PDT
Created attachment 657951 [details] [diff] [review]
fix
Comment 22 Joe Drew (not getting mail) 2012-09-04 14:39:55 PDT
Comment on attachment 657951 [details] [diff] [review]
fix

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

Oh my, that's an unsatisfying fix. :( At least we can test for it!
Comment 23 Lukas Blakk [:lsblakk] use ?needinfo 2012-09-04 15:59:10 PDT
Joe/Roc: we're spinning a 15.0.1 tomorrow for desktop at least and I'd like to know what you think the risks/rewards would be for having this fix as a ride-along.  Are we seeing this being a serious enough issue for canvas users over the next 4 weeks or is there too much potential fallout in other areas touched by this patch that make this not worth considering.  Please get in touch before tomorrow morning with your take.
Comment 24 Joe Drew (not getting mail) 2012-09-04 19:12:39 PDT
This feels safe, but also seems to happen in a fairly specific set of circumstances, so I don't think we *definitely* want it in 15.0.1. If roc wants it in, sure.
Comment 25 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-09-05 03:36:46 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/00d23ffe3105
Comment 26 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-09-05 03:38:49 PDT
Lukas, I think we should take this in 15.0.1, primarily because it's super duper safe, but also because simple pages can easily be affected by this.
Comment 27 Lukas Blakk [:lsblakk] use ?needinfo 2012-09-05 15:36:45 PDT
We checked a few sites, and without any user feedback coming in on input we decided not to hold 15.0.1 for this. Lets get it uplifted to Beta 16 though.
Comment 28 Ryan VanderMeulen [:RyanVM] 2012-09-05 19:42:35 PDT
https://hg.mozilla.org/mozilla-central/rev/00d23ffe3105
Comment 29 ryancalderoni 2012-09-06 08:31:14 PDT
This bug broke my HTML5 image viewer, the image no longer shows up on page load but a click on the screen or a window re-size, etc, will trigger the render.

I tried updating to beta 16 but it still happens, does milestone mozilla18 mean it will be in version 18.0?
Comment 30 Scoobidiver (away) 2012-09-06 10:53:21 PDT
(In reply to ryancalderoni from comment #29)
> I tried updating to beta 16 but it still happens, does milestone mozilla18
> mean it will be in version 18.0?
It will be soon in Firefox 16.0 Beta and Aurora 17.0. Check the tracking flags.
Comment 31 Lukas Blakk [:lsblakk] use ?needinfo 2012-09-06 11:32:58 PDT
(In reply to ryancalderoni from comment #29)
> This bug broke my HTML5 image viewer, the image no longer shows up on page
> load but a click on the screen or a window re-size, etc, will trigger the
> render.
> 
> I tried updating to beta 16 but it still happens, does milestone mozilla18
> mean it will be in version 18.0?

It will be in Firefox 16 beta 3 next week if this gets nominated, approved, and landed to mozilla-beta before next Monday. Aurora nom will get this in 17 sooner (the following night after landing).
Comment 32 Scoobidiver (away) 2012-09-12 02:48:36 PDT
Approved for Beta/Aurora but not landed!
Comment 33 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-09-12 16:25:08 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/0cb18d00bb5c
https://hg.mozilla.org/releases/mozilla-beta/rev/1c1b707222c9
Comment 34 Simona B [:simonab] 2012-09-24 09:16:34 PDT
Verified on Win XP with Firefox 16 beta 4 (using the provided URL and the test case attached in the description, with/without HWA) that mousemove event does not fail to draw content on canvas.

Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Comment 35 Akash 2012-10-12 22:49:54 PDT
Issue seems to have fixed in the latest Firefox 16.1v
Comment 36 Simona B [:simonab] 2012-10-19 08:27:02 PDT
Verified as fixed on Firefox 17 beta 2 - the mousemove event does not fail to draw content on canvas (used the test case attached in the description with HWA on/off).

Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Firefox/17.0

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