The test case for bug 901841[1] should cause an error to be logged to the console about the invalid regular expression using within the 'pattern' attribute of the <input> field. mozregression gives this: mozilla-central: Last good revision: 58c5a3427997 (2014-05-16) First bad revision: 2893f60d5903 (2014-05-17) Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58c5a3427997&tocha nge=2893f60d5903 mozilla-inbound: Last good revision: cf89b5d018f8 First bad revision: 2893f60d5903 https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cf89b5 d018f8&tochange=2893f60d5903 Without knowing the code I assume this is related to bug 976446, so I CCed Brian. Sebastian [1] https://bugzilla.mozilla.org/attachment.cgi?id=786154

The JS engine is reporting the error in the regexp correctly, but nsContentUtils::IsPatternMatching ignores that failure, clears the pending exception and pretends the result was a match.

Trying someone on the DOM side, then

I'm surprised this regressed, looking at the code, though I think bholley cleaned up at least some of the error reporting stuff somewhat recently. I don't think there's any reason we couldn't just report the error, though...

This seems to do the trick. There's no page-visible exception because we do everything in the junk scope (so we simply report a message to the console).

Thank you!

https://hg.mozilla.org/integration/mozilla-inbound/rev/93c8e1dfed14 https://hg.mozilla.org/integration/mozilla-inbound/rev/f017644da2e2

https://hg.mozilla.org/mozilla-central/rev/93c8e1dfed14 https://hg.mozilla.org/mozilla-central/rev/f017644da2e2

I just realized that I never verified this. It's working fine for me in Firefox 46.0.1 with a little nit, which I filed now as bug 1272297. Sebastian