SC.Buttons inside of form tags trigger form submission #2
Comments
|
Closing this since there's also an open pull request. |
Merged
rwjblue
referenced
this issue
in rwjblue/ember.js
Oct 20, 2013
rwjblue
added a commit
that referenced
this issue
Jul 10, 2014
upgrade es3-safe-recast to not be broken :)
nickiaconis
added a commit
to nickiaconis/ember.js
that referenced
this issue
Jun 1, 2016
locks
added a commit
that referenced
this issue
Aug 16, 2017
# This is the 1st commit message: typo in comment # The commit message #2 will be skipped: # indent yuidoc comment # The commit message #3 will be skipped: # remove IE8 test # The commit message #4 will be skipped: # remove commented out test # The commit message #5 will be skipped: # use file path and add imports # # Used RFC #176 modules API for imports. # Also cleaned up some of the globals-mode usage. # The commit message #6 will be skipped: # clean up more globals style documentation # The commit message #7 will be skipped: # Updates blueprints # The commit message #8 will be skipped: # remove extra type check # The commit message #9 will be skipped: # [BUGFIX beta] Reusing element causes problems in Safari # # When testing allowed input types, in some versions of Safari the type # cannot be change to `file` if previously set to a different one. # # Fixes #14727 # The commit message #10 will be skipped: # [DOC release]missed code block added # The commit message #1 will be skipped: # [DOC release] Update wait.js - Add missing backticks to code snippet. # The commit message #2 will be skipped: # use safe `toString` for array content in `mixins/array` # The commit message #3 will be skipped: # avoid expanding already expanded property key in computed.sort # The commit message #4 will be skipped: # avoid expanding already expanded property key in reduceMacro/arrayMacro/multiArrayMacro # The commit message #5 will be skipped: # [DOC release] Make `Ember.expandProperties` public # The commit message #6 will be skipped: # reuse meta `arrayContentDidChange` # The commit message #7 will be skipped: # replace `throw` with assertion in `enumerable` # The commit message #8 will be skipped: # [BUGFIX beta] Allow boolean values for current-when # # As the docs say, `A link will be active if current-when is true`. # Looks like this might have been broken since 1.13 and #12344 # did not seem to actually fix this particular bug. # # Related issues: # # - #12512 # - #12630 (fix was not merged) # - #12296 # The commit message #9 will be skipped: # remove unused imports # The commit message #10 will be skipped: # [DOC] Improve Ember.isEmpty # The commit message #1 will be skipped: # micro optimization in `enumerable`
rwjblue
referenced
this issue
in rwjblue/ember.js
Feb 13, 2018
During the Ember 2.15 cycle glimmer-vm was updated and contained a new format for AST plugins. This required that all "legacy" plugins be wrapped (to avoid breakage of this intimate API). When the wrapping code was implemented two distinct bugs were introduced that would have caused custom AST transforms to be called many more times than in Ember < 2.15. Bug #1: Accruing AST Transforms via re-registration --------------------------------------------------- ember-cli-htmlbars allows addons to register AST plugins via the normal ember-cli preprocessor registry system. When this support was added it was not possible to provide plugins during a specific compilation, and therefore all plugins are registered globally (even by current ember-cli-htmlbars versions). Due to the mechanism that ember-cli uses to build up the list of addons and dependencies for use at build time ember-cli-htmlbars ends up requiring the template compiler many times and subsequently registering any AST transform plugins that are present using the exported `registerPlugin` API. Since this tracks plugins in module state it is possible to have `registerPlugin` called many times with the same plugin. ember-cli-htmlbars attempts to mitigate the polution of plugins by forcing the require.cache of the template compiler module to be flushed. Unfortuneately, there are circumstances where this cache invalidation doesn't work and we therefore grow the number of registered AST plugins _very_ quickly (once for each nested addon / engine / app that is in the project). During the 2.15 glimmer-vm upgrade the previous deduping logic was removed (due to the fact that "legacy" AST transforms were always generating unique plugin instances). When combined with situations where ember-cli-htmlbars was not properly clearing the require cache the resulting build times of complex applications using AST plugins grew > double. Bug #2: Legacy AST Transform Compat Bug --------------------------------------------------- In order to avoid breakage in addons leveraging the intimate AST plugin APIs a wrapper layer was added. Unfortunately, the wrapper layer assumed that there would only be a single `Program` node. However, in glimmers AST every `BlockStatement` has a `Program` node (and _may_ have an inverse with another `Program` node). This mistake meant that the legacy "wrapped" AST transforms would be instantiated and ran _many_ times per-template which generates quite a bit of wasted work. Fixes Included -------------- * Bring back the deduplication code ensuring that a given AST plugin is only registered once. * Fix the legacy AST transform wrapper code to _only_ instantiate and invoke the legacy AST transform once for the outermost `Program` node.
rwjblue
added a commit
that referenced
this issue
Feb 14, 2018
During the Ember 2.15 cycle glimmer-vm was updated and contained a new format for AST plugins. This required that all "legacy" plugins be wrapped (to avoid breakage of this intimate API). When the wrapping code was implemented two distinct bugs were introduced that would have caused custom AST transforms to be called many more times than in Ember < 2.15. Bug #1: Accruing AST Transforms via re-registration --------------------------------------------------- ember-cli-htmlbars allows addons to register AST plugins via the normal ember-cli preprocessor registry system. When this support was added it was not possible to provide plugins during a specific compilation, and therefore all plugins are registered globally (even by current ember-cli-htmlbars versions). Due to the mechanism that ember-cli uses to build up the list of addons and dependencies for use at build time ember-cli-htmlbars ends up requiring the template compiler many times and subsequently registering any AST transform plugins that are present using the exported `registerPlugin` API. Since this tracks plugins in module state it is possible to have `registerPlugin` called many times with the same plugin. ember-cli-htmlbars attempts to mitigate the polution of plugins by forcing the require.cache of the template compiler module to be flushed. Unfortuneately, there are circumstances where this cache invalidation doesn't work and we therefore grow the number of registered AST plugins _very_ quickly (once for each nested addon / engine / app that is in the project). During the 2.15 glimmer-vm upgrade the previous deduping logic was removed (due to the fact that "legacy" AST transforms were always generating unique plugin instances). When combined with situations where ember-cli-htmlbars was not properly clearing the require cache the resulting build times of complex applications using AST plugins grew > double. Bug #2: Legacy AST Transform Compat Bug --------------------------------------------------- In order to avoid breakage in addons leveraging the intimate AST plugin APIs a wrapper layer was added. Unfortunately, the wrapper layer assumed that there would only be a single `Program` node. However, in glimmers AST every `BlockStatement` has a `Program` node (and _may_ have an inverse with another `Program` node). This mistake meant that the legacy "wrapped" AST transforms would be instantiated and ran _many_ times per-template which generates quite a bit of wasted work. Fixes Included -------------- * Bring back the deduplication code ensuring that a given AST plugin is only registered once. * Fix the legacy AST transform wrapper code to _only_ instantiate and invoke the legacy AST transform once for the outermost `Program` node. (cherry picked from commit a95e314)
rwjblue
added a commit
that referenced
this issue
Feb 14, 2018
During the Ember 2.15 cycle glimmer-vm was updated and contained a new format for AST plugins. This required that all "legacy" plugins be wrapped (to avoid breakage of this intimate API). When the wrapping code was implemented two distinct bugs were introduced that would have caused custom AST transforms to be called many more times than in Ember < 2.15. Bug #1: Accruing AST Transforms via re-registration --------------------------------------------------- ember-cli-htmlbars allows addons to register AST plugins via the normal ember-cli preprocessor registry system. When this support was added it was not possible to provide plugins during a specific compilation, and therefore all plugins are registered globally (even by current ember-cli-htmlbars versions). Due to the mechanism that ember-cli uses to build up the list of addons and dependencies for use at build time ember-cli-htmlbars ends up requiring the template compiler many times and subsequently registering any AST transform plugins that are present using the exported `registerPlugin` API. Since this tracks plugins in module state it is possible to have `registerPlugin` called many times with the same plugin. ember-cli-htmlbars attempts to mitigate the polution of plugins by forcing the require.cache of the template compiler module to be flushed. Unfortuneately, there are circumstances where this cache invalidation doesn't work and we therefore grow the number of registered AST plugins _very_ quickly (once for each nested addon / engine / app that is in the project). During the 2.15 glimmer-vm upgrade the previous deduping logic was removed (due to the fact that "legacy" AST transforms were always generating unique plugin instances). When combined with situations where ember-cli-htmlbars was not properly clearing the require cache the resulting build times of complex applications using AST plugins grew > double. Bug #2: Legacy AST Transform Compat Bug --------------------------------------------------- In order to avoid breakage in addons leveraging the intimate AST plugin APIs a wrapper layer was added. Unfortunately, the wrapper layer assumed that there would only be a single `Program` node. However, in glimmers AST every `BlockStatement` has a `Program` node (and _may_ have an inverse with another `Program` node). This mistake meant that the legacy "wrapped" AST transforms would be instantiated and ran _many_ times per-template which generates quite a bit of wasted work. Fixes Included -------------- * Bring back the deduplication code ensuring that a given AST plugin is only registered once. * Fix the legacy AST transform wrapper code to _only_ instantiate and invoke the legacy AST transform once for the outermost `Program` node. (cherry picked from commit a95e314)
rwjblue
added a commit
that referenced
this issue
Feb 14, 2018
During the Ember 2.15 cycle glimmer-vm was updated and contained a new format for AST plugins. This required that all "legacy" plugins be wrapped (to avoid breakage of this intimate API). When the wrapping code was implemented two distinct bugs were introduced that would have caused custom AST transforms to be called many more times than in Ember < 2.15. Bug #1: Accruing AST Transforms via re-registration --------------------------------------------------- ember-cli-htmlbars allows addons to register AST plugins via the normal ember-cli preprocessor registry system. When this support was added it was not possible to provide plugins during a specific compilation, and therefore all plugins are registered globally (even by current ember-cli-htmlbars versions). Due to the mechanism that ember-cli uses to build up the list of addons and dependencies for use at build time ember-cli-htmlbars ends up requiring the template compiler many times and subsequently registering any AST transform plugins that are present using the exported `registerPlugin` API. Since this tracks plugins in module state it is possible to have `registerPlugin` called many times with the same plugin. ember-cli-htmlbars attempts to mitigate the polution of plugins by forcing the require.cache of the template compiler module to be flushed. Unfortuneately, there are circumstances where this cache invalidation doesn't work and we therefore grow the number of registered AST plugins _very_ quickly (once for each nested addon / engine / app that is in the project). During the 2.15 glimmer-vm upgrade the previous deduping logic was removed (due to the fact that "legacy" AST transforms were always generating unique plugin instances). When combined with situations where ember-cli-htmlbars was not properly clearing the require cache the resulting build times of complex applications using AST plugins grew > double. Bug #2: Legacy AST Transform Compat Bug --------------------------------------------------- In order to avoid breakage in addons leveraging the intimate AST plugin APIs a wrapper layer was added. Unfortunately, the wrapper layer assumed that there would only be a single `Program` node. However, in glimmers AST every `BlockStatement` has a `Program` node (and _may_ have an inverse with another `Program` node). This mistake meant that the legacy "wrapped" AST transforms would be instantiated and ran _many_ times per-template which generates quite a bit of wasted work. Fixes Included -------------- * Bring back the deduplication code ensuring that a given AST plugin is only registered once. * Fix the legacy AST transform wrapper code to _only_ instantiate and invoke the legacy AST transform once for the outermost `Program` node. (cherry picked from commit a95e314)
kyleshay
pushed a commit
to kyleshay/ember.js
that referenced
this issue
Mar 21, 2018
During the Ember 2.15 cycle glimmer-vm was updated and contained a new format for AST plugins. This required that all "legacy" plugins be wrapped (to avoid breakage of this intimate API). When the wrapping code was implemented two distinct bugs were introduced that would have caused custom AST transforms to be called many more times than in Ember < 2.15. Bug emberjs#1: Accruing AST Transforms via re-registration --------------------------------------------------- ember-cli-htmlbars allows addons to register AST plugins via the normal ember-cli preprocessor registry system. When this support was added it was not possible to provide plugins during a specific compilation, and therefore all plugins are registered globally (even by current ember-cli-htmlbars versions). Due to the mechanism that ember-cli uses to build up the list of addons and dependencies for use at build time ember-cli-htmlbars ends up requiring the template compiler many times and subsequently registering any AST transform plugins that are present using the exported `registerPlugin` API. Since this tracks plugins in module state it is possible to have `registerPlugin` called many times with the same plugin. ember-cli-htmlbars attempts to mitigate the polution of plugins by forcing the require.cache of the template compiler module to be flushed. Unfortuneately, there are circumstances where this cache invalidation doesn't work and we therefore grow the number of registered AST plugins _very_ quickly (once for each nested addon / engine / app that is in the project). During the 2.15 glimmer-vm upgrade the previous deduping logic was removed (due to the fact that "legacy" AST transforms were always generating unique plugin instances). When combined with situations where ember-cli-htmlbars was not properly clearing the require cache the resulting build times of complex applications using AST plugins grew > double. Bug emberjs#2: Legacy AST Transform Compat Bug --------------------------------------------------- In order to avoid breakage in addons leveraging the intimate AST plugin APIs a wrapper layer was added. Unfortunately, the wrapper layer assumed that there would only be a single `Program` node. However, in glimmers AST every `BlockStatement` has a `Program` node (and _may_ have an inverse with another `Program` node). This mistake meant that the legacy "wrapped" AST transforms would be instantiated and ran _many_ times per-template which generates quite a bit of wasted work. Fixes Included -------------- * Bring back the deduplication code ensuring that a given AST plugin is only registered once. * Fix the legacy AST transform wrapper code to _only_ instantiate and invoke the legacy AST transform once for the outermost `Program` node. (cherry picked from commit a95e314)
2 tasks
chriskrycho
added a commit
that referenced
this issue
Nov 16, 2022
# This is the 1st commit message: Distinguish `Factory` and `InternalFactory` Like with our distinction between `Owner` and `InternalOwner`, the notion of a `Factory` as we use it internally is somewhat richer than what we provide as a public interface. Thus, add an `InternalFactory` type which extends the public `Factory` interface, and update the internals which previously referred to `Factory` to refer to the new type instead. In a future cleanup pass, we can likely remove many of these uses of `InternalFactory` in favor of using *only* the public API for `Factory` from instead, and that will help smooth the path to removing many of these unnecessary extra details. # The commit message #2 will be skipped: # InternalFactory needs Factory :sigh:
chriskrycho
added a commit
that referenced
this issue
Nov 17, 2022
# This is the 1st commit message: Distinguish `Factory` and `InternalFactory` Like with our distinction between `Owner` and `InternalOwner`, the notion of a `Factory` as we use it internally is somewhat richer than what we provide as a public interface. Thus, add an `InternalFactory` type which extends the public `Factory` interface, and update the internals which previously referred to `Factory` to refer to the new type instead. In a future cleanup pass, we can likely remove many of these uses of `InternalFactory` in favor of using *only* the public API for `Factory` from instead, and that will help smooth the path to removing many of these unnecessary extra details. # The commit message #2 will be skipped: # InternalFactory needs Factory :sigh:
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using sproutcore-2.0.a.2.js inside an existing HTML page.
I rendered a collection nested inside a form tag. A form submission is triggered when clicking on an SC.Button. If I move the collection outside of the form tag it works as expected.
The text was updated successfully, but these errors were encountered: