Closed Bug 787623 Opened 12 years ago Closed 12 years ago

mousemove event fails to draw content on canvas

Categories

(Core :: Graphics: Canvas2D, defect)

Product:
Core
Component:
Graphics: Canvas2D
Version:
15 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla18
Tracking Flags:
Tracking Status
firefox15 - affected
firefox16 + verified
firefox17 --- verified

People

(Reporter: abedi0501, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression, verifyme)

Attachments

(2 files)

test.html
744 bytes, text/html
Details
fix
5.44 KB, patch
joe
: review+
lsblakk
: approval-mozilla-aurora+
lsblakk
: approval-mozilla-beta+
Details | Diff | Splinter Review
Attached file 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
Summary: HTML5 problems → HTML5 problem on Firefox 15
Making it onmousemove="window.drawline()" works... Not sure what's messing us up here.
URL: http://software.hixie.ch/utilities/js...
Component: Untriaged → DOM
Product: Firefox → Core
Can be observed here http://jsfiddle.net/bV54P/2/
Attachment #657538 - Attachment mime type: text/plain → text/html
Your attached testcase works for me.
Severity: normal → major
Something to do with invalidation? On linux I need to force repaint to see the line.
not really sure whats wrong, facing the same issue on Ubuntu 12 with Firefox 15 installed !!
We need the regression range here. http://harthur.github.com/mozregression/ should be useful tool.
Keywords: regressionwindow-wanted
Or just download various builds to narrow down the range when the behavior changed. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
It worked fine in Firefox 14 tough
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
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/
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
Firefox 15 was in Nightly 12+ weeks ago.
FF15 nightly builds started in late April. Run something like: mozregression --good=2012-04-24
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
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
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.
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
Status: UNCONFIRMED → NEW
tracking-firefox16: --- → ?
Ever confirmed: true
Component: DOM → Canvas: 2D
Keywords: regressionwindow-wanted → regression
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.
Summary: HTML5 problem on Firefox 15 → Canvas problem on Firefox 15
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.
Attached patch fix — — Splinter Review
Assignee: nobody → roc
Attachment #657951 - Flags: review?(joe)
Blocks: 787892
Blocks: 773097
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!
Attachment #657951 - Flags: review?(joe) → review+
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.
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.
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.
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.
tracking-firefox15: ? → -
https://hg.mozilla.org/mozilla-central/rev/00d23ffe3105
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
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?
(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.
status-firefox17: --- → affected
(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).
Attachment #657951 - Flags: approval-mozilla-beta?
Attachment #657951 - Flags: approval-mozilla-aurora?
Attachment #657951 - Flags: approval-mozilla-beta?
Attachment #657951 - Flags: approval-mozilla-beta+
Attachment #657951 - Flags: approval-mozilla-aurora?
Attachment #657951 - Flags: approval-mozilla-aurora+
Approved for Beta/Aurora but not landed!
Keywords: verifyme
Summary: Canvas problem on Firefox 15 → mousemove event fails to draw content on canvas
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
status-firefox16: fixed → verified
QA Contact: simona.marcu
Issue seems to have fixed in the latest Firefox 16.1v
Status: RESOLVED → VERIFIED
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
status-firefox17: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: