Note: There are a few cases of duplicates in user autocompletion which are being worked on.

mousemove event fails to draw content on canvas

VERIFIED FIXED in Firefox 16

Status

()

Core
Canvas: 2D
--
major
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Akash, Assigned: roc)

Tracking

({regression, verifyme})

15 Branch
mozilla18
x86
Windows XP
regression, verifyme
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15- affected, firefox16+ verified, firefox17 verified)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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
(Reporter)

Updated

5 years ago
Summary: HTML5 problems → HTML5 problem on Firefox 15
Making it onmousemove="window.drawline()" works... Not sure what's messing us up here.
Component: Untriaged → DOM
Product: Firefox → Core
(Reporter)

Comment 2

5 years ago
Can be observed here http://jsfiddle.net/bV54P/2/

Updated

5 years ago
Attachment #657538 - Attachment mime type: text/plain → text/html

Comment 3

5 years ago
Your attached testcase works for me.
(Reporter)

Comment 4

5 years ago
Also, confirmed at http://stackoverflow.com/questions/12225678/html5-problems-in-firefox-15/12225724
(Reporter)

Updated

5 years ago
Severity: normal → major

Comment 5

5 years ago
Something to do with invalidation? On linux I need to force repaint to see the line.
(Reporter)

Comment 6

5 years ago
not really sure whats wrong, facing the same issue on Ubuntu 12 with Firefox 15 installed !!

Comment 7

5 years ago
We need the regression range here.
http://harthur.github.com/mozregression/ should be useful tool.
Keywords: regressionwindow-wanted

Comment 8

5 years ago
Or just download various builds to narrow down the range when the behavior changed.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
(Reporter)

Comment 9

5 years ago
It worked fine in Firefox 14 tough
(Reporter)

Comment 10

5 years ago
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/
(Reporter)

Comment 12

5 years ago
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.

Comment 14

5 years ago
FF15 nightly builds started in late April.

Run something like:
mozregression --good=2012-04-24
(Reporter)

Comment 15

5 years ago
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

5 years ago
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.

Comment 18

5 years ago
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

Updated

5 years ago
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.

Updated

5 years ago
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.
Created attachment 657951 [details] [diff] [review]
fix
Assignee: nobody → roc
Attachment #657951 - Flags: review?(joe)

Updated

5 years ago
Blocks: 787892

Updated

5 years ago
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.
status-firefox15: --- → affected
status-firefox16: --- → affected
tracking-firefox15: --- → ?
tracking-firefox16: ? → +
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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/00d23ffe3105
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
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18

Comment 29

5 years ago
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

5 years ago
(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+

Comment 32

5 years ago
Approved for Beta/Aurora but not landed!
https://hg.mozilla.org/releases/mozilla-aurora/rev/0cb18d00bb5c
https://hg.mozilla.org/releases/mozilla-beta/rev/1c1b707222c9
status-firefox16: affected → fixed
status-firefox17: affected → fixed
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
(Reporter)

Comment 35

5 years ago
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.