…ons (ogizanagi)This PR was merged into the 3.3 branch.Discussion----------[Form][Profiler] Fixes form collector triggering deprecations| Q             | A| ------------- | ---| Branch?       | 3.3 <!-- see comment below -->| Bug fix?      | yes| New feature?  | no <!-- don't forget updating src/**/CHANGELOG.md files -->| BC breaks?    | no| Deprecations? | no <!-- don't forget updating UPGRADE-*.md files -->| Tests pass?   | yes| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->| License       | MIT| Doc PR        | N/ASince 3.3, if you inspect your logs when accessing the form profiler panel, you'll see some of these:```shphp.INFO: User Deprecated: The Symfony\Bundle\WebProfilerBundle\Twig\WebProfilerExtension::dumpValue() method is deprecated since version 3.2 and will be removed in 4.0.[...] at /src/Symfony/Bundle/WebProfilerBundle/Twig/WebProfilerExtension.php:119```The [WebProfilerExtension](https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/WebProfilerBundle/Twig/WebProfilerExtension.php#L73) is still using a `ValueExporter` instance for BC reasons when the $value ins't an instance of `Data` and this BC layer will be removed in 4.0 (so it'll throw an exception/error when trying to use it with something else than a `Data` instance).The issue is since#21638, collectors (including forms one) have been drastically simplified to leverage the "seamless usage of Data clones", which is great!... But there is a slightly different implementation between `Data::seek()` and [`Data::__get()`](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/VarDumper/Cloner/Data.php#L123-L130). There are probably good reasons for this, but it prevents from using classic Twig property access when the underlying data may be a scalar (`null`, `false`, ...).I already spot that while working on the [Validator panel](https://github.com/symfony/symfony/pull/22554/files#diff-deac3c5ce4aa87243093dcd6a3f77a56R84). Perhaps there is a better solution, though.Anyway, current `master` is currently broken, as it still tries to use the `ValueExporter`, which is already removed. And removing the BC layer in `WebProfilerExtension` isn't enough for now. It needs this fix.BTW it also fixes rendering of the concerned inlined-dumps:|Before|After||--|--||<img width="818" alt="screenshot 2017-06-03 a 13 35 25" src="https://cloud.githubusercontent.com/assets/2211145/26753222/01a692e6-4862-11e7-90d5-9cc9e4832648.PNG">|<img width="817" alt="screenshot 2017-06-03 a 13 35 47" src="https://cloud.githubusercontent.com/assets/2211145/26753224/090d5d6c-4862-11e7-87c1-73d5346f602c.PNG">|Commits-------9de898d [Form][Profiler] Fixes form collector triggering deprecations

…rt decision.object being null (ogizanagi)This PR was merged into the 3.3 branch.Discussion----------[SecurityBundle] Fix the datacollector to properly support decision.object being null| Q             | A| ------------- | ---| Branch?       | 3.3 <!-- see comment below -->| Bug fix?      | yes| New feature?  | no <!-- don't forget to update src/**/CHANGELOG.md files -->| BC breaks?    | no| Deprecations? | no <!-- don't forget to update UPGRADE-*.md files -->| Tests pass?   | yes| Fixed tickets |#24804 <!-- #-prefixed issue number(s), if any -->| License       | MIT| Doc PR        | N/ASimilar to#23050, when accessing a `Data` clone property through `__get()` and the value is `null` for instance, you'll really get `null` instead of a `Data` instance. The solution is to use `seek` instead whenever we access and try to use `profiler_dump` on a `Data` property that can be a simple scalar like `null` or `false`. AFAIK, `decision.object` is the only one here.Commits-------769a5f2 [SecurityBundle] Fix the datacollector to properly support decision.object being null