`setErrorParameter` of error view with `HasErrorParameter<NotFoundException>` called for non-HTML requests

Description of the bug / feature

If a Vaadin 14 application contains a class that implements HasErrorParameter<NotFoundException>, the setErrorParameter method gets invoked for any request that returns a 404 error, even for e.g. image requests (when the requested image is missing).

Minimal reproducible example

PageNotFoundView.java:

@ParentLayout(MainLayout.class)
public class PageNotFoundView extends VerticalLayout implements HasErrorParameter<NotFoundException> {

    @Override
    public int setErrorParameter(BeforeEnterEvent event, ErrorParameter<NotFoundException> parameter) {
        add(new Span("Oh no, not found"));
        return 404;
    }
}

OtherView.java:

    Image image = new Image("not_found.jpeg", "alt");
    add(image);

Expected behavior

setErrorParameter doesn’t get invoked when navigating into OtherView

Actual behavior

setErrorParameter gets invoked, even though the PageNotFoundView is never displayed in the UI. The request for the image also gets a text/html response, which is against the request’s accept string.

Versions:

- Vaadin / Flow version: 14.5.4
- Java version: 11
- OS version: Windows
- Browser version (if applicable): n/a
- Application Server (if applicable): Spring Boot / Tomcat (n/a) 
- IDE (if applicable): n/a

[Legioth]

The Accept header is constructed based on the URL.

In which browser is that? I tested with Chrome, where it seems to only vary based on where the URL is used but not based on the contents of the URL.

No matter what URL prefix I use (I tested missing.html, missing.jpg and missing.js), I always get the same Accept header based on where I use the URL.

Usage type	Accept value
Address bar, clicking a link, <iframe>	text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
<img>	image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
<link rel="stylesheet">	text/css,*/*;q=0.1

Scripts and webfonts are indeed difficult to distinguish since at least my Chrome requests those as */*.

We don’t need to have perfect logic for when to create an UI instance and when not, but the more cases we can avoid confusion, the better.

• Anything with text/html in the group with highest priority should certainly cause a UI to be created.
• If we want to slightly reduce the risk of regressions, then we could consider to also create a UI for requests with text/html at a lower priority, or with only */* as the only value.
• We should definitely not create an UI if the browser doesn’t at all ask for text/html or if it has */* only to supplement some more specific request.

[vaadin-bot]

This ticket/PR has been released with Vaadin 23.0.2.