Bauke Scholtz

> You are right i might look into just fixing the credit card JS which isn't really receiving updates anyway these days! It would probably be cool if you simply...

Yeah, deprecate as early as possible. Along with a WARN log when it's being used to make the developer aware.

Norepro. A reproducer is helpful. This case is also already covered by `FullAjaxExceptionHandlerIT`: https://github.com/omnifaces/omnifaces/blob/4.4/src/test/java/org/omnifaces/test/exceptionhandler/fullajaxexceptionhandler/FullAjaxExceptionHandlerIT.java#L179-L202

Still, a reproducer is helpful because I cannot reproduce this. Most probably your error page is extending from a template which submits a form during page load via e.g. commandScript/remoteCommand....

You've hit an incredible corner case there. Jakarta Faces normally won't restore the view of an error page, but fails to do so when the servlet container (Tomcat) doesn't set...

Ok you're welcome. Note that the FullAjaxExceptionhandler won't be executed when the request did not hit the FacesServlet. Forged requests don't necessarily target the FacesServlet either. For this you'd need...

> Probably fixing Tomcat should be the most convenient solution... ? Guess so. But I also want to improve Mojarra on that and take a second look at the Faces...

jakarta.servlet.error.exception is absent on non-exceptional errors such as 404, 400, etc so that's not a feasible way. > or check if old "message" request attribute is "present" I already checked,...

Indeed, already saw it.

Indeed, we should check both. Please continue in Mojarra repo. This is not OmniFaces related. I realized I forgot to create ticket, so here it is https://github.com/eclipse-ee4j/mojarra/issues/5528