$default can be string
minor #10184 [Console] $default can be string (Jmoati)

This PR was submitted for the 2.3-dev branch but it was merged into the 2.3 branch instead (closes #10184).

Discussion
----------

[Console] $default can be string

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT

Commits
-------

39ab7f3 [Console] $default can be string
[HttpKernel] fixed wrong reference in TraceableEventDispatcher
Fixed recursion level incrementing in FlattenException::flattenArgs().
bug #10195 [Debug] Fixed recursion level incrementing in FlattenException::flattenArgs(). (sun)

This PR was submitted for the 2.3-dev branch but it was merged into the 2.3 branch instead (closes #10195).

Discussion
----------

[Debug] Fixed recursion level incrementing in FlattenException::flattenArgs().

The internal `$level` variable for tracking the recursion level is pre-incremented on the parent level of the recursion already.

This causes later array elements in an array that has more than 10 elements to get obscured by `'*DEEP NESTED ARRAY*'`, even though the elements are on the first/top level of the array.

The incremented `$level` value needs to be passed to the recursive call to `FlattenException::flattenArgs()` only.

Discovered in debugging exceptions in Drupal (which happens to use very large multi-dimensional arrays for legacy reasons).

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

Commits
-------

1b1501b Fixed recursion level incrementing in FlattenException::flattenArgs().
added missing @deprecated tag
minor #10188 [TwigBundle] added missing @deprecated tag (fabpot)

This PR was submitted for the 2.3-dev branch but it was merged into the 2.3 branch instead (closes #10188).

Discussion
----------

[TwigBundle] added missing @deprecated tag

Commits
-------

ee08582 [TwigBundle] added missing @deprecated tag
bug #10191 [HttpKernel] fixed wrong reference in TraceableEventDispatcher (fabpot)

This PR was merged into the 2.3 branch.

Discussion
----------

[HttpKernel] fixed wrong reference in TraceableEventDispatcher

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #9748, #9727
| License       | MIT
| Doc PR        | n/a

This PR fixes #9748 and #9727 by removing the `id` state. Only private method signatures have been changed, so that qualifies for a fix in 2.3.

The `getNotCalledListeners()` is a bit special as it tries to get non-called listeners. It passes `null` as the event id as if a listener has been called more than once, getting the first call is enough.

Commits
-------

acd3317 [HttpKernel] fixed wrong reference in TraceableEventDispatcher
[DomCrawler] Fixed incorrect handling of image inputs
bug #10205 [DomCrawler] Fixed incorrect handling of image inputs (robbertkl)

This PR was merged into the 2.3 branch.

Discussion
----------

[DomCrawler] Fixed incorrect handling of image inputs

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #10204
| License       | MIT
| Doc PR        |

A possible approach to fix #10204, but I'm open to suggestions to fix this another way, as this might not be the most 'elegant' way.

Initially, my thoughts were to create a new DomCrawler\Field\FormField subclass, especially for image inputs. However, this does not solve the problem, because such a FormField would still exist under 1 name in the FormFieldRegistry.

Instead, I've changed it to have 2 separate FormFields instead (which both reference the same input node), with different names (.x and .y) so that both values can be set separately and will both be submitted.

Commits
-------

816cf17 [DomCrawler] Fixed incorrect handling of image inputs
[DomCrawler] Fixed filterXPath() chaining
bug #10207 [DomCrawler] Fixed filterXPath() chaining (robbertkl)

This PR was merged into the 2.3 branch.

Discussion
----------

[DomCrawler] Fixed filterXPath() chaining

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | debatable (see below)
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #10206
| License       | MIT
| Doc PR        |

As @stof mentions in #10206, each node in the Crawler can belong to a different \DOMDocument. Therefore, I've made each node do its own XPath, relative to itself, and add all the results to a new Crawler. This way, all resulting nodes are still part of their original \DOMDocument and thus can reach all of their parent nodes.

No current tests break on this change. I've added a new test for this case, by checking if the number of parents is correct after obtaining a node through chaining of `filterXPath()`.

Now for BC: I can think of a number of cases where this change would give a different result. However, it's debatable/unclear if:
- the old behavior was a bug in the first place (which would validate this change), or
- the old behavior was intended (which would make this a BC breaking change)

As an example, consider the following HTML:
```html
<div name="a"><div name="b"><div name="c"></div></div></div>
```
What would happen if we run this:
```php
echo $crawler->filterXPath('//div')->filterXPath('div')->filterXPath('div')->attr('name');
```
Aside from breaking reachability of the parent nodes by chaining, with the original code it would echo 'a'.
With this patch it would echo 'c', which, to me, makes more sense.

Commits
-------

43a7716 [DomCrawler] Fixed filterXPath() chaining
removing dead code.
minor #10219 [EventDispatcher] removing dead code. (inalgnu)

This PR was submitted for the 2.3-dev branch but it was merged into the 2.3 branch instead (closes #10219).

Discussion
----------

[EventDispatcher] removing dead code.

| Q             | A
| ------------- | ---
| Bug fix?      | [no]
| New feature?  | [no]
| BC breaks?    | [no]
| Deprecations? | [no]
| Tests pass?   | [yes]
| Fixed tickets | [n/a]
| License       | MIT
| Doc PR        | [n/a]

Commits
-------

e28395f [EventDispatcher] removing dead code.
renamed variables - making next change more readable
reduced recursion when building DumperPrefixCollection
bug #10215 [Routing] reduced recursion in dumper (arnaud-lb)

This PR was submitted for the 2.3-dev branch but it was merged into the 2.3 branch instead (closes #10215).

Discussion
----------

[Routing] reduced recursion in dumper

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | sensiolabs/SensioFrameworkExtraBundle/issues/275
| License       | MIT

This reduces recursion in the route dumper, avoiding issues with xdebug's recursion limit.

Commits
-------

fa6eebc reduced recursion when building DumperPrefixCollection
9278b27 renamed variables - making next change more readable
fixed various inconsistencies
minor #10234 Various minor changes (fabpot)

This PR was merged into the 2.3 branch.

Discussion
----------

Various minor changes

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | n/a
| License       | MIT
| Doc PR        | n/a

Commits
-------

eb3f6c6 fixed various inconsistencies
Fix "Array was modified outside object" in ResizeFormListener.

The onSubmit() method of the ResizeFormListener class is assuming the data is an array, and calling unset directly inside a foreach. This works fine in most scenarios, but if data is an instance of IteratorAggregate, it breaks with the following error:

Symfony\Component\Form\Extension\Core\EventListener\ResizeFormListener::onSubmit(): ArrayIterator::next(): Array was modified outside object and internal position is no longer valid in ./vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Core/EventListener/ResizeFormListener.php line 142

This is because the foreach loop is using an Iterator in the background, but the ResizeFormListener has unset the underlying data directly, causing the Iterator and data to be out of sync. When the data is an instance of IteratorAggregate, the loop should use the iterator directly and not rely on foreach.

The onSubmit method has been updated accordingly.