1694719 - Background image is not rendered on vanguardcanada.ca

Status: NEW

(Core :: DOM: Navigation, defect, P3)

Description

[Ksenia Berezina [:ksenia]]

Attachment: Screen Shot 2021-02-24 at 12.00.04 PM.png

This was initially reported in https://github.com/webcompat/web-bugs/issues/67404

Steps to Reproduce:

1. Open https://www.vanguardcanada.ca/individual/questionnaire.htm#/ in Firefox Nightly 88.0a1 (2021-02-24)
2. Click "Begin the questionnaire"
3. Scroll down to question 9 (don't worry about answering the questions)

Expected:
The bar graph image is displayed

Actual:
The bar graph image is missing

The following css is used to set the background-image:

.IQ9 {
    height: 184px;
    width: 314px;
    background-position: center left;
    background-image: url(../images/q9.png);
}

The problem is intermittent, I've noticed that the image appears sometimes. It also appears if I change the css in devtools panel, for example disable/enable a rule.

Comment 1

[Timothy Nikkel (:tnikkel)]

The image load gets cancelled (imgRequestProxy::Cancel) with this stack:
#01: mozilla::net::nsLoadGroup::Cancel
#02: nsDocLoader::Stop()
#03: nsDocShell::Stop
#04: nsDocShell::InternalLoad
#05: nsDocShell::OnLinkClickSync
#06: OnLinkClickEvent::Run()

So the async link click event that gets triggered by clicking on the button (which is a link to "unsafe:javascript:void(0)")

So seems like either a bug in the link click code or a bug in the page.

Comment 2

[Timothy Nikkel (:tnikkel)]

We only call Stop in InternalLoad here

https://searchfox.org/mozilla-central/rev/31a3457890b5698af1277413ee9d9bd6c5955183/docshell/base/nsDocShell.cpp#9464

if it is NOT a javascript uri we are navigating to. In this case the page source has "javascript:void(0)" but dumping the uri in InternalLoad I get unsafe:javascript:void(0) The page dom has that too. It looks like the angular.js library used on the page has code with "unsafe:" so I guess it adds the unsafe?

Comment 3

[Timothy Nikkel (:tnikkel)]

Sometimes in Safari clicking on the button navigates to unsafe:javascript:void(0), which Safari refuses to do and shows an error page. So I think this is probably a site issue (although I don't fully understand what's going on so I'll leave room for that be incorrect, but I'm halting my investigation here).

Comment 4

[Ksenia Berezina [:ksenia]]

Attachment: 67404-1.html

Thanks for the analysis! Indeed it seems that unsafe is added by angular.js, so <a href="javascript:void(0)">Begin the questionnaire</a> is being changed to <a href="unsafe:javascript:void(0)">Begin the questionnaire</a>. There are ways to prevent this from happening by changing angular's compiler service configuration (or using event.preventDefault() instead of javascript:void(0)). Given that this is also affecting Safari in a more severe manner, I agree that this is something that preferably should be fixed by the site. I'll try to reach out to them.

As for the difference between Chrome and Firefox, I've created a testcase reproducible 100% of the time. There is window.scrollTo(0, 0); being used, which seems to be the culprit here (not sure how important this is, given that the behavior is triggered by clicking on a link with unsafe:javascript )

Comment 5

[Jim Blandy :jimb]

For triage purposes, since the compat issue here seems to be introduced by Firefox's response to an attempt to navigate to an invalid URL, I've changed the component to DOM: Navigation.

Comment 6

[Chris Peterson [:cpeterson]]

Does the HTML spec say what the expected behavior should be? We should probably ignore these loads to avoid breaking sites.

Assigning to kmag because he will add a special case to recognize the unsafe: pseudo-protocol and abort the load attempt. This is an ugly workaround, but Angular is a popular framework and we want these sites to work in Firefox, not just Chrome.

P3

Comment 7

[Karl Dubost💡 :karlcow]

Maybe this needs another look.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.