Closed Bug 1746886 Opened 4 years ago Closed 4 years ago

When I reload the page after scrolling down, the image on the certain sites does not show up until I scroll to the top.

Categories

(Core :: Layout, defect)

Desktop
Windows 10
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox97 --- affected

People

(Reporter: alice0775, Unassigned)

References

Details

(Keywords: nightly-community, parity-chrome, testcase)

Attachments

(1 file)

I find a bug when I test Bug 1745638.

This is not a recent regression, I also reproduce the issue in Firefox60....
Step to reproduce:

  1. Open https://www.qrz.com/db/DG2YCB (not necessary login)
    --- the image(picture of the man at the desk) will display --- As expected
  2. Scroll down (rotate the mouse wheel one notch)
  3. Reload the page (F5)
    --- observe, the image would not display. Instead, it shows up asDG2YCB, Uwe. --- BUG
  4. Scroll to top
    --- the image(picture of the man at the desk) will display again.

Actual results:
When I reload the page after scrolling down, the image on the certain sites does not show up until I scroll to the top.

Expected Results:
The image should display after reload without scroll to to top.

See Also: → 1745638

Hi all, on my computer doing the four steps like Alice0775White described has the following effect:
1.) FF 95.0.2, 64-bit, Windows 10 Pro:
After steps 1+2 -> pictures and text all there.
After step 3 -> pictures and text all gone (on the 'Biography' tab only)
After step 4 -> pictures and text still not there (meaning that I cannot reproduce that scrolling on top changes anything)
2.) FF 93 portable, 64-bit, Windows 10 Pro:
After steps 1+2 -> pictures and text all there.
After step 3 -> pictures and text all there
After step 4 -> pictures and text all there (meaning that there seems to be no bug with FF 93 on Windows)
3.) FF 95, Linux Mint 20.2:
After steps 1+2 -> pictures and text all there.
After step 3 -> pictures and text all gone (on the 'Biography' tab only)
After step 4 -> pictures and text still not there (meaning that I cannot reproduce that scrolling on top changes anything)
3.) FF 94, Linux Mint 20.2:
After steps 1+2 -> pictures and text all there.
After step 3 -> pictures and text all there
After step 4 -> pictures and text all there (meaning that there seems to be no bug with FF 94 on Linux Mint)
73 (=regards) de Uwe, DG2YCB

Working on a reduced testcase
Having stripped a lot out, the behaviour now is that when the page loads, no images are displayed until I scroll down
I'm not sure how much more I'm going to be able to take out, there's a lot of javascript

Attached file Reduced testcase
Keywords: testcase

Unlike the issue in 1745638, this does not appear to be a regression - with the testcase, I am able to reproduce it as far back as 50

One additional observation which may help to identify the defect: 2 minutes ago I got again a white space instead of the content of the 'Biography' tab of my https://www.qrz.com/db/DG2YCB page, and pushing the reload button did not help. Then, for testing, I opened a new Firefox tab and opened there the same page (https://www.qrz.com/db/DG2YCB page). Result: Everything was displayed as it should.
Could it be that the defect has something to do with writing/reading the cache?

The test was done with FF 95.0.2 (64-bit) on Windows 10. (My FF 93 portable still runs well, without any issue.)

TBH I am confused. I am seeing the same behavior on Chrome. Is it just a behavior what the site is doine?

Hi Hiro, First I was thinking this too. But why is then FF 93 as well as all older versions FREE FROM THIS BUG? Is still 100% reproducible here.

The severity field is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The page seems to be doing some weird stuff with JS. The proximal cause for the image not showing up is that the image does not have a src attribute. The element initially looks like this (note that it uses the user-defined data-src attribute, not the "real" src attribute):

<img alt="DG2YCB, Uwe" data-loading="lazy" data-src="https://cdn-bio.qrz.com/b/dg2ycb/Shack_DG2YCB_logo.jpg?p=0d80562e9214cbae8a14f000096e5623" style="height:450px; width:800px">

(This img element lives inside of an <iframe> whose document seems to be dynamically built up in JS, BTW.)

When the image does show up, it's because the page has a JS callback called loadImages that loops over the images and sets src based on the data-src. If that callback never gets invoked, the image doesn't show up. Here's that function (from the source of https://www.qrz.com/db/DG2YCB ):

    "loadImages": function () {
        var imgs = jQuery(x).find("img[data-loading=lazy], input[data-loading=lazy]").get();
        var loadable = [];
[...SNIP: some code here that populates 'loadable'...]
        for (i = 0; i < loadable.length; i +=1) {
            img = loadable[i];
            img.removeAttribute("data-loading");
            img.setAttribute("src", img.getAttribute("data-src"));
            img.removeAttribute("data-src");
        }

The page schedules the loadImages callback in response to the JQuery "ready" and "resize scroll touchmove" events, like this:

[...]
    'triggerLoad' : function() {
        clearTimeout( lazyLoader.timer );
        lazyLoader.timer = setTimeout( function() {
            lazyLoader.loadImages();
        },10);
    }
};

jQuery(document).on("ready", function() {
    lazyLoader.triggerLoad();
});
jQuery(window).on("resize scroll touchmove", function() {
    lazyLoader.triggerLoad();
});

It looks like they're using the JQuery ready event as a signal for the page having fully-loaded (and they're also trying to gracefully also allow the images to load earlier-than-that in response to user input, i.e. resize/scroll/touch -- that's why the image appears after you scroll).

However, it seems "ready" isn't a reliably-fired signal: https://api.jquery.com/ready/ says "Note that if the DOM becomes ready before this event is attached, the handler will not be executed." I'm guessing that's what's happening here.

Flags: needinfo?(dholbert)

So I'm guessing the behavior-differences here (across browser versions) are due to Firefox performance improvements (or something to that effect) where the DOM is now "becoming ready" before the callback is attached (which results in the callback never firing, per my above-quoted JQuery documentation).

So: this seems like a website bug, particularly given that it's reproducible in multiple browsers. The site should not be depending on this potentially-never-firing ready JQuery event for the loading of important parts of the page.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

I think you are all on the wrong track, guys. My complaint is NOT that sometimes some images are not shown, but that THE ENTIRE CONTENT OF THE BIOGRAPHY TAB IS NOT DISPLAYED. No text, no graphics, just a fully white page. And as said, this bug came on Windows with the update from FF 93 to 94.
See my uploaded pictures for Bug 1745638 (https://bugzilla.mozilla.org/show_bug.cgi?id=1745638).

(In reply to Dr. Uwe Risse from comment #12)

I think you are all on the wrong track, guys. My complaint is NOT that sometimes some images are not shown, but that THE ENTIRE CONTENT OF THE BIOGRAPHY TAB IS NOT DISPLAYED.

I was diagnosing the originally-reported bug here, which was about the image not displaying (see comment 0 as well as the title of this bug, "When I reload the page after scrolling down, the image on the certain sites does not show up until I scroll to the top.")

The issue you're bringing up seems to be covered on the separate bug that you linked to (bug 1745638) - can we discuss that over there?

(I suspect it's a version of the same underlying problem with the page having fragile/faulty dependency on JS running, but we can further confirm/investigate on bug 1745638.)

er, "originally-reported" was a bad choice of words, since your bug was the "original" bug report about this particular QRZ site. :) But I think/hope you understand what I'm saying. In any case, let's proceed back on bug 1745638.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: