The option “prompt” takes precedence over “forceApprovalPrompt”.
Valid options for “prompt” are “consent”, “none”, “select_account” or a
combination. i.e. “select_account+consent”.
We fixed the stack overflow in Blaze materialization by using
a "work stack" pattern instead of recursing.
Putting local variables on the heap hurts readability and doesn't
help performance; it was just saving us 16 bytes or so (or whatever
two local variables is) per nested View.
#let currently re-renders the entire template when an argument
changes, so in this case:
```
<template name="spacebars_template_test_let_rerender">
<input type="text" class="foo">
{{#let y=x}}
<span class="bar">{{y}}</span>
{{/let}}
</template>
```
...when `x` changes, the input and span are destroyed and recreated.
This slightly alters the reg ex, because now there has to be at least
one character in name, whereas it could have been empty before. This
should be
irrelevant since the whole packageDot function only makes sense if name
is not empty.
We should be doing a lexicographical comparison of path components, rather
than including the `/` characters in the comparison, to match the order
given by the Unix `find` or `ls` commands.
Fixes#4300.
This leak occured whenever a DOM element with attributes got removed
from the DOM without destroying its containing view. For example, an
element in an `{{#if}}` whose condition is toggled back and forth; a
single Blaze.View is used for the `{{#if}}` as its condition changes.
The retention chain was as follows:
The element was saved in the `elem` variable of `materializeTag` in
materializer.js.
Among other places, `elem` was saved in the `attrUpdater` in that
function, which is used by the `updateAttributes` function.
This function is passed to `view.autorun`, which registered this
`onViewDestroyed` handler:
self.onViewDestroyed(function () { locals.c.stop(); });
That callback retains a references to the computation, and thus to the
DOM element.
Before this commit, that onViewDestroyed callback is not removed from
the Blaze.View when the computation is stopped (eg, because the DOM
element is removed from the DOM, triggering
`updaterComputation.stop()`), so in this case the DOM element is leaked.
(This still has a tiny leak in that you end up with lots of nulls
inside `_callbacks.destroyed`; using a better data structure for
callbacks is a game for another day.)
Fixes#4289.
This fixes a crash when two architectures need to be downloaded
for the same package. It happens when building for non-host architecture
if packages have not been cached yet.
Crash happened because progress object got reused for another download request,
and progress objects are not supposed to be reused.
