My user has sent me screenshots of Chrome on ThinkPad Windows 10 displaying the Toolset GRID and GALLERY blocks incorrectly — see 4 screenshots: Grid Wrong, Gallery wrong, Correct columns, Chrome version.
The page where this can be seen is hidden link
Yesterday I reported this on Explorer but since that is no longer supported by Microsoft we don't care. But Chrome should work on all platforms. Chrome on Mac and Asus PC works fine. But current Chrome on ThinkPad Windows 10 does not appear to.
Also connected with the GALLERY Block as I was editing it, I noticed a back-end problem in Safari:
1. Only Full Size image was allowed (major issue)
2. changing the gallery style from Grid to Masonry and then back to Grid did not work in the back-end. If you go from Grid style to Masonry style then to Collage style, then you can get back to Grid style (this is a minor issue)
3. Sometimes toggling the CROP switch in Grid style caused images to no longer display properly cropped. This could be fixed by editing the gallery in the media library and inserting an image and then deleting it again. This forced the gallery to work properly. (minor but irritating issue)
I have attached 2 back-end images of the back-end gallery block problem as well - file labels explain — Gallery-Grid-cropped-wrong1, Gallery-Grid-cropped-wrong.
Many thanks for looking at this. I'm only trying to help Toolset be a better product - that is why I report any bugs I find.
Hi Martin,
We encourage and appreciate your reports.
Feedback and suggestions are very important to us, as they help us improve in the right direction.
As per my understanding, ThinkPad is just a product line/series from a manufacturer (Lenovo) and it shouldn't have any specification wise difference in terms of the operating system or browser.
For instance, the grid items show correctly on my HP laptop, with the latest Windows 10 and Chrome ( Version 87.0.4280.66 (Official Build) (64-bit) - same as your screenshot ).
Screenshot: hidden link
I'm also a bit confused by the 3 screenshots from the user on ThinkPad. The screenshots Grid Wrong, Gallery wrong, and Correct columns all seem to be taken from the same browser, device, and screen, yet two of them show the grid incorrectly, while the third shows it correctly.
Some questions that are relevant for this investigation are:
1. What was the difference in how these 3 screenshots were captured?
2. Is this happening only in Chrome on this device or has the user checked any other browser too?
( for example Firefox or Edge etc )
3. Does login or logout status has any effect on this?
4. Is there any browser extension enabled in the browser, which can interfere with the "Flex" CSS property, used for the grid layout?
5. What is the screen resolution of the device where the issue can be seen?
All these answers will help us in further investigation.
Note: I've split a new ticket for the report related to gallery block's editing in Safari. One of my colleagues with Mac OS will follow up accordingly.
( ref: https://toolset.com/forums/topic/split-bug-gallery-block-back-end-editing-problems-in-safari/ )
regards,
Waqar
Thanks for the reply. Yes it is confusing-The page looks fine on my Mac in Chrome and Safari as well as on my Asus PC in Chrome and Edge.
1. Regarding the 3 screenshots, the 3rd correct one is the fels.ca homepage included to show how the columns are supposed to look. (not the test page at fels.ca/test where I used the Toolset blocks). On the home page I had to switch to regular Gutenberg columns/ and gallery to make it work on this ThinkPad.
2. this is happening on Chrome and Explorer on this ThinkPad but not Microsoft Edge which works.
3. There is only 1 login to the device that I'm aware of. So not sure of the answer here-I'll report back
4. Not sure about browser extension(s). I will ask and report back. That sounds like the most likely culprit...
5. I will have to check on screen resolution. This is a two monitor setup in addition to the laptop but I believe it has shown up on more than one screen - again I'll have to check and report back.
Thanks so much again.
Thanks for writing back and I'll wait for the rest of the answers.
About question 3, sorry I should have been more clear. We're interested to know if logging into the website's WP admin area has any effect or not.
( device's login/user is not relevant here )
Update-
1. MS Edge is not present on the ThinkPad - just Chrome and Explorer - it is a company controlled laptop so the user cannot install things - so it was incorrect for me to say earlier that the columns displayed correctly on Edge because it wasn't tested - sorry
2. after logging in to WordPress with admin credentials there was no change to the front end display - still wrong
3. screen resolutions (2 monitors and laptop) in these screenshots: hidden link , hidden link , hidden link
4. Here is a screenshot showing the Chrome extensions: hidden link (looks like Google Docs Offline, Docs, Sheets, Slides ) - unfortunately since this is a company IT controlled computer we cannot remove the extensions to try it without... - perhaps you can try putting the extensions in the current version of Chrome on a PC and see if the grid and gallery blocks work?
Hope this helps. Really appreciate you trying to help get the bugs out of Toolset Grid and Gallery blocks in this situation on ThinkPad Windows 10 with Chrome.
Thank you for sharing this update.
Unfortunately, this data on its own is not very conclusive and we haven't received any other report about a similar issue with the Toolset's grid block.
I do have a couple of theories to investigate this isolated report, but they'll require some further cooperation from your user:
1. Toolset's grid block depends on the 'grid-template-columns' CSS property. You can request the user to try the demo examples of the grids on that device, from these links:
hidden link
hidden link
hidden link)
This will help in narrowing down if the issue is limited to Toolset's grid block or the device/browser is not rendering grid-template-columns CSS property in general.
If the user can't view the grid examples from these example links, it will mean that the device/group administrator may have intentionally or unintentionally restricted certain CSS specifications from the browser. This is especially relevant because this grid-template-columns property was available from Chrome 29 to Chrome 57, as an experimental feature.
2. Th other possibility is that for some reason, not all CSS styles are getting loaded on the user's device.
The best way to see that would be using Chrome's inspect element tool, as shown in this screen capture video:
hidden link
If your user could share a similar screen capture showing the CSS styles applied to the elements from my video, that would be very helpful.
Here is my report:
1. no problem viewing any of the 3 links you provided - that can't be the issue
2. I think we may be closer to the problem here. I have enclosed 4 brief videos showing the Chrome console on the computer as you requested:
hidden link
hidden link
hidden link
hidden link
And also screenshots of three 403 errors in the console showing possibly why the browser is not rendering correctly with the links to the Toolset css which is not loading on this computer.
hidden link
hidden link
hidden link
I think this might explain why the columns are not rendering? Does this make any sense to you?
Thank you for sharing these screen captures.
Since the "style.css" file from the Blocks plugin is not loading on that device with error 403, that explains the layout issues.
Can you check with the user if he can access and view this file directly in the browser?
hidden link
Yes it is visible no problem at all in Chrome when she clicks on it!
If that file is loading in the browser correctly, it means that there is no file permission issue at the server level.
( besides the web page is successfully loading these files for everyone except this user )
To recap what we know so far, for this particular device, a CSS file is not loading from inside the web page with 403 (Forbidden) error, but, the same file loads in the same browser, when opened alone.
I'm afraid, I can't think of any other logical explanation for this except that there is some extreme cache or firewall filtering involved, on this particular device. Have you considered involving your host's support or that device's company administrator in this investigation? It is possible that they may have encountered something similar before.
