www.community-orchard.org.uk - see bug description

[webcompat-bot]

URL: http://www.community-orchard.org.uk/gallery
Browser / Version: Firefox 44.0
Operating System: Ubuntu
Problem type: Something else - I'll add details below

Steps to Reproduce

1. Navigate to: http://www.community-orchard.org.uk/gallery
2. Images are missing, see screenshot (really could do with being able to upload two images, one from Chrome and one from FireFox so the difference can be seen; only FF one uploaded). Load the same page with Chrome, Safari or Silk and the images are displayed correctly. Not just my device either, other users have the same problem when using FF. Note that this is a Google site and if I roll back to June 2015 all the images appear in FF, but as soon as I change the page the problems start.

Expected Behavior: 16 images and their labels should be loaded in the main page frame

Actual Behavior: only 7 images and labels, and a couple of unaccompained labels appear

[karlcow]

Screenshot on opera blink. Confirmed.

[karlcow]

This one will be a hard one, because I guess it's hitting the maximum depth of html parsing in Gecko. The code is just terrible. There are paths such as the one below and all the divs are empty.

td.sites-layout-tile:nth-child(3) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > span:nth-child(1) > b:nth-child(1) > div:nth-child(1) > span:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > b:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > b:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > b:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > font:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(2) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1) > div:nth-child(1)

I wonder what is producing this code. What the commenter meant by " Note that this is a Google site"
It would be cool to know how the site was generated. Ah probably generated with the in-house tools of Google Sites. Note that it is server side.

http -b GET http://www.community-orchard.org.uk/gallery

This provides the same insanity without JS execution.
https://en.wikipedia.org/wiki/Google_Sites

[karlcow]

@hsivonen knows probably more about the limit of our HTML5 parsing algorithm compared to the one of blink.

[karlcow]

Just to illustrate the insanity of the code. Let's add a bit of CSS property to visualize what is happening.

Watch out for your eyes. :) Click on the image to see it at real size or see below for a detail.

A detail.

[hsivonen]

Gecko's limit is in layout, but the HTML parser enforces this in order not to reach the limit on the layout side.

I'd happily remove the parser check for the limit if layout got rid of the limitation.

[hallvors]

This issue seems well understood - removing the needsdiagnosis label. We just need to decide whether to close it as a duplicate of the open Gecko but or contacting them to recommend the code is somewhat simplified..

[karlcow]

To contact them:
http://www.community-orchard.org.uk/contact-us

just a pinch of salt they probably don't know what they are doing and it's why they are using Google Sites.

[adamopenweb]

I left a quick message about the bug in the contact form. Let's see if we get a response.

[community-orchard]

Hi, I got your message, thanks. I administer the site. You are correct this site was created using Google Sites tools, no actual code was written by us. The page in question is the only one on the site that experiences this problem, and as I explained above it renders correctly in other browsers. How can I help you to help me?

[karlcow]

@community-orchard Thanks a lot.
Could you tell us how the page was created? Is it a wysiwyg UI or something with a pre-built template?
If the code is generated by the Google Sites tools, we could try to contact Google about it, but we need to know a bit more what is the process for creating such a page.

[community-orchard]

Well, the site itself is based on a template but the whole thing is wysiwyg tools. Not really sure what you mean by 'pre-built template' - can you explain?

[karlcow]

pre-built template: A template given by Google Sites UI.

(thinking out loud: I wonder why the tool creates so many nested divs, maybe to align images and the system doesn't know how to reduce the complexity. There are ways to clean this code either with tables, lists or flexbox, but that would require manual fixing, so maybe too difficult).

[community-orchard]

OK, I created the main part of this page using wysiwyg tools. The page is divided into three columns using the layout tools, then I've inserted photos from Picasa with labels, then linked the images to other pages on the site. Like this:

[community-orchard]

There are a lot of images on the page, and I add new ones periodically and always to the top of the left column, shifting the existing ones to the right and then to the next row. I wonder if making changes in this way after the code has been generated causes the problem.

Anyway, once the page has been created, I can actually view and modify directly the HTML, but I'm not confident to do that, and I'm guessing that the code should be re-written rather than just be tweaked, right?

[karlcow]

@community-orchard Thanks a lot for helping.
Yes the code could be definitely rewritten.

Something with this pattern could work:
http://codepen.io/anon/pen/LNMjgQ?editors=1100

  <figure>
    <a href="http://www.community-orchard.org.uk/gallery/wassail-2016"><img src="" /></a>
    <figcaption>Title 3</figcaption>
  </figure>

  <figure>
    <a href=""><img src="" /></a>
    <figcaption>Title 4</figcaption>
  </figure>
</div>

and the associated CSS.

.photos { 
 display:flex;
flex-direction: row;
justify-content: space-between;
  flex-wrap: wrap;
}

but not sure if Google Sites will damage this in the future with the wysiwyg tool.

[hallvors]

We should ask Google contacts if anyone is working on Google Sites at the moment. Their markup generating code clearly has some room for improvements..

[karlcow]

SeeAlso: https://bugzilla.mozilla.org/show_bug.cgi?id=1285546
Another bug for Google Sites which is similar.

[adamopenweb]

This issue still exists.

[softvision-sergiulogigan]

The issue has been fixed.

Tested with:
Browser / Version: Firefox Nightly 69.0a1 (2019-06-10)
Operating System: Linux Mint