Symfony version(s) affected

^6.1.0

Description

Since 6.1.0, DomCrawler is using by default the masterminds/html5 parser (previously a dev requirement).

And that's causing any HTML having a form with a submit button like <button type="submit" ...> to end with error because the parser (resulting DomElement) is returning <button type="button" ...> and BrowserKit doesn't process those, only the former.

And, unless I'm wrong (I perfectly could be), that's incorrect: the type="submit" attribute should be preserved.

I'm not sure if this is something to report @ Mastermind's or here or in BrowserKit, or in BrowserKit Mink driver... but, for sure it all has started with the bump to DomCrawler ^6.1.0 and the default use of the new parser and it seems to be a "buggy" behaviour of the parser.

I've searched @ Mastermind/html5, BrowserKit and DomCrawler and have been unable to find this issue reported.

Downgrading to DomCrawler 6.0.* "fixes" the problems, because that version is not using the new parser by default.

How to reproduce

Try to run any mink/behat test using Browserkit with a form having a <button type="submit" ...> being part of a form. It will fail with error:

Behat\Mink\Driver\BrowserKitDriver supports clicking on links and submit or reset buttons only. But "button" provided (Behat\Mink\Exception\UnsupportedDriverActionException

Possible Solution

• Downgrade to DomCrawler 6.0 [OR]
• Configure the environment to ensure that the new parser is not being used [OR]
• Fix the bug (if it's a bug) in the new parser.

Additional Context

I'm happy reporting this in the parser if you consider that it should be fixed there. For me <button type="button" ...> sounds plain wrong, but I'm not an expert.

Sorry if the issue doesn't fulfil all the expectations, that's all the information I've been able to discover till now, following the thread over all the involved components.

Ciao :-)