Closed Bug 631117 Opened 14 years ago Closed 14 years ago

js1k demo no longer working

Categories

(Core :: Graphics: Canvas2D, defect)

Product:
Core
Component:
Graphics: Canvas2D
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 623437
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: gal, Unassigned)

References

(
URL
)

Details

(Keywords: qawanted, regression)

http://js1k.com/2010-first/demo/635 This worked the last time I looked at it a few weeks ago.
blocking2.0: --- → ?
Keywords: qawanted
Could we get some help with a regression range here?
(also works in webkit-based browsers)
Confirmed. Old rendering stays around instead of being cleared. Could be explained by the background being rendered as transparent instead of opaque.
Keywords: regression, regressionwindow-wanted
Note: confirmed on linux, so it's not OS-specific.
OS: Mac OS X → All
Happens also without GL layers. Not a GL layers bug.
bug 617319 sticks out. I remember that causing problems before. bjacob?
Seems likely to be a problem similar to the one in bug 623437
Demo has: for ($ in C = c.getContext('2d')) C[$[J = X = Y = 0] + ($[6] || '')] = C[$]; So yeah, this is the arc/arcTo thing just like in bug 623437.
Blocks: 617319
So, how can we fix that? Is that a bug in the demo or on our side?
That depends on your definition of "bug". The demo relies on a particular enumeration order, and we recently changed that order. None of this is specified. But it seems like a regression to me.
We're not fixing this for 2.0.
So this demo only ever worked on Firefox? I mean, if the enumeration order is unspecified, presumably other browsers don't use the same?
It's unspecified, but that doesn't mean it's not interoperable... to a degree. At least in terms of whether arc or arcTo comes first.
Depends on: 623437
This is basically bug 623437; let's take the discussion there.
This works in every browser but us, and it used to work in FF a month ago.
Why wasn't this duped to bug 623437? /be
Because we hadn't decided whether to fix or evang.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Bug 623437 comment 16 seemed to have no effect, and bug 623437 comment 17 gave me no hope. What made "we" decide to fix rather than evang? I'm all in favor of fixing, in case it isn't obvious. Not that that mattered at the time of the bug 623437 comment 16 and 17 exchange! :-| /be
> What made "we" decide to fix rather than evang? The fact that I though of a small safe fix. At least that certainly swayed _my_ decision!
To be clear, of a small safe fix for the particular ordering change the demos really really depend on not happening, not other ordering changes we also introduced.
Cool -- you rock! /be
blocking2.0: ? → final+
You need to log in before you can comment on or make changes to this bug.