[whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?

[Justin Novosad]

On Thu, Mar 6, 2014 at 11:47 AM, Rik Cabanier <cabanier at gmail.com> wrote:

>
>
>
> On Thu, Mar 6, 2014 at 8:31 AM, Justin Novosad <junov at google.com> wrote:
>
>>
>>
>>
>> On Wed, Mar 5, 2014 at 11:42 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>>
>>> Testing all browsers (except IE
>>> since document.implementation.createHTMLDocument() doesn't work) they seem
>>> to handle canvas contexts with no browsing context except when you use text.
>>> Chrome crashes, firefox throws an exception and Safari draws the text
>>> with a very small scale [1]
>>>
>>
>> Thanks for checking.  The reason I started this thread is that I just
>> recently solved the crash in Chrome, and I wasn't satisfied with my
>> resolution.  I just added an early exit, so Chrome 35 will fail silently on
>> calls that depend on style resolution when the canvas has no browsing
>> context.  So now we have three different behaviors. Yay!
>>
>> I don't think the Safari behavior is the right thing to do because it
>> will never match the developer's intent.
>> Basically it boils down to two yes/no questions:
>> 1) exception or no exception?
>> 2) block all canvas APIs just the text APIs?
>>
>> I think that throwing an exception makes sense in this case because it
>> would provide meaningful feedback to the developer.  I was reluctant to do
>> that when I fixed the crash in Chrome because there is always a chance of
>> breaking working apps/sites when you add exceptions where there weren't
>> before or where there aren't in other browsers (not to mention the spec).
>>  But since Firefox is already throwing an exception in this case, I would
>> feel comfortable doing that in Chrome as well.
>>
>
> Maybe I wasn't very clear. The exception on Firefox happens when you try
> to use the text API, not when you try to create the context.
>

You were clear, and I think that makes sense because, as Boris stated,
elements can be transferred from one document to another.  So blocking
context creation does not solve the issue unless, as you stated, we also
added check at the API method level. So... we really just need checks on
the text APIs.


> For question 2) I really don't have a strong opinion.  On some level,
>> being more restrictive feels safer and more future proof, but would it be
>> overkill in this case?
>>
>
> Since the canvas element can be transferred to a browser context-less
> document, throwing an exception at creation time won't work.
> It seems best to disallow the API that rely on the browser context which
> as far as we know are the text APIs.
>

Yes, that is what I meant. My only concern is what if future changes to the
spec make make other APIs suddenly become dependent on the browsing
context? Disallowing all CanvasRenderingContext2D API calls seems safer in
this case, or am I worrying too much?


>
>
>> As far as Path2D text methods are concerned, I don't see any problems.
>> the resolution of CanvasDrawingStyles can be deferred to rasterization
>> time, at which point we can use the browsing context of the canvas to which
>> the path is being drawn.
>>
>
> Maybe... the point of the path API is to help with performance. If they
> are designed in such a way that the actual processing happens when they are
> used, performance will be impacted.
>

Well, the fully resolved path can be cached.