Forum is messed up when viewed in Firefox v.

[phantom_x]

Up until yesterday, the forums were displaying fine with no issues (Firefox 75.0). As of yesterday, they now look like this:

https://imgur.com/a/LLZjaL0

Thinking it might have been an addon error, I restarted FF in safe mode i.e. no addons enabled, and it still displayed like that. However, on Chrome it displays fine, as always (no addons running). What gives? Can you please look into this? I even checked the VBB site and there was no recent mention of this problem. If you can address what is happening and rectify that, it would be appreciated. The forums are really difficult to read otherwise.

[Cordovan]

It looks like your version of Firefox is reading the page as a mobile browser, and using the default Mobile Style of vBulletin. At the bottom of the page there should be a link to go to the full site, and clicking that should restore the forums to their proper display.

[phantom_x]

It looks like your version of Firefox is reading the page as a mobile browser, and using the default Mobile Style of vBulletin. At the bottom of the page there should be a link to go to the full site, and clicking that should restore the forums to their proper display.

Ahh, thank you very much for the quick reply Cordovan! I'm not sure why it switched to that but I am grateful for the quick resolution posted. Cheers!

[koriolis]

It looks like your version of Firefox is reading the page as a mobile browser, and using the default Mobile Style of vBulletin. At the bottom of the page there should be a link to go to the full site, and clicking that should restore the forums to their proper display.

Also, if you don't mind me barging in and going slightly off-topic, but... maybe some love could be directed towards reducing the image assets of both the forums and the main site?
I mean they are now in the multi-megabyte range and with re-using a few drag-&-drop compression tools you can shave-off megabytes from those images and make the main site as well as the forums that much speedier (and substantially reduce bandwidth and storage costs for SSG).
This is an easy operation that shouldn't require code-changes or fiddle-ing with vBulletin and whatever system you guys have to use for the site.

For example, the forum background image "community.jpg" can be reduced from 1.3Mb to 396Kb without loss of quality.
The image from the site "ssg_3192020.jpg" goes from 1.4Mb to 328Kb without loss of quality.
Just on those 2 images you'll be saving almost 2Mb of bandwith and storage.

More importantly, your users will thank you profusely for speedier sites.

Thanks.

[Rauven]

It looks like your version of Firefox is reading the page as a mobile browser, and using the default Mobile Style of vBulletin. At the bottom of the page there should be a link to go to the full site, and clicking that should restore the forums to their proper display.

But what about the DDO Market? It's been messed up in Firefox for a long time. Here's a side-by-side with Firefox on the left and Chrome on the right.

https://i.imgur.com/a8E1Bdz.png

[phantom_x]

But what about the DDO Market? It's been messed up in Firefox for a long time. Here's a side-by-side with Firefox on the left and Chrome on the right.

https://i.imgur.com/a8E1Bdz.png

Yes, to add further I am experiencing the same display problems in FF for the store. Further to that on a tangential issue (fresh topic I posted) it has recently (within the last day or so) timing out on transactions so I cannot even purchase things. Anyways, lots of bugs to address.

[DYWYPI]

For the 'DDO Market' they erroneously have HTML Syntax in one of the CSS files LOL. However, the main problem is the actual links to the CSS files aren't functioning and thus not applying any styles, when viewed with Firefox, the ampersands in the links probably don't help.

[DYWYPI]

In other words Jerry (DDO Market) the following CSS file, which has & (ampersand) in the URI isn't being applied in Firefox.

https://drh.img.digitalriver.com/sto...File=style.css

That file of course would apply the main CSS styles like the background colour it's probably not the file that's wrong it's likely the occurrence of the ambiguous ampersands in the URI link.

For example:

In this fragment, the attribute's value is "?bill&ted":

<a href="?bill&ted">Bill and Ted</a>

In the following fragment, however, the attribute's value is actually "?art©", not the intended "?art&copy", because even without the final semicolon, "&copy" is handled the same as "©" and thus gets interpreted as "©":

<a href="?art&copy">Art and Copy</a>

To avoid this problem, all named character references are required to end with a semicolon, and uses of named character references without a semicolon are flagged as errors.

[Rauven]

In other words Jerry (DDO Market) the following CSS file, which has & (ampersand) in the URI isn't being applied in Firefox.

https://drh.img.digitalriver.com/sto...File=style.css

That file of course would apply the main CSS styles like the background colour it's probably not the file that's wrong it's likely the occurrence of the ambiguous ampersands in the URI link.

For example:

In this fragment, the attribute's value is "?bill&ted":

<a href="?bill&ted">Bill and Ted</a>

In the following fragment, however, the attribute's value is actually "?art©", not the intended "?art&copy", because even without the final semicolon, "&copy" is handled the same as "©" and thus gets interpreted as "©":

<a href="?art&copy">Art and Copy</a>

To avoid this problem, all named character references are required to end with a semicolon, and uses of named character references without a semicolon are flagged as errors.

In addition to that the first two stylesheet href links in the code for the Market say:

<link rel="stylesheet" href="//drh.img.digitalriver.com/...

I saved the page locally and edited the two links to add "https:" like the third link:

<link rel="stylesheet" href="https://drh.img.digitalriver.com/...

While the page still didn't fully render as it does in Chrome (it was looking for some assets locally) the stylesheets were at least applied by just making that one change. The ampersands might be causing other issues, but it appears their incomplete href links for the stylesheets are the primary cause for the stylesheets not loading.

[DYWYPI]

Really, as best practice they should be using HTTPS, i.e. "https://". The plain starting "//" in those links to the CSS file is a "network-path reference" https://tools.ietf.org/html/rfc3986#section-4.2 for allowing mixed mode content from either: HTTP/HTTPS 'Server served' file versions.

[DYWYPI]

If you look at the Internet Archive: 2 May 2019, which displays correctly in Firefox. You'll see the ampersands are correctly (re)written as: & in the file to the "store" CSS file.

Archived page: http://web.archive.org/web/201905021...oryID=58516200

The browser doesn't seem to have any issue with the "//" in the archived version.

Archived "store" CSS file: http://web.archive.org/web/201905021...File=style.css

Because it is pulling the correct images from that specific file, e.g. the large background image: u21_dr_wrapper.jpg

html {
  font-size: .625em;
  background: #000000 url(//web.archive.org/web/20190502113513im_/https://drh.img.digitalriver.com/DRHM/Storefront/Site/ssg/cm/images/2012/lotro/u21_dr_wrapper.jpg) no-repeat center top;
}

It's certainly not the Firefox web browser at fault. The "//" should function when it's being delivered on an actual HTTP Web Server; if I wasn't clear enough before, remember it's 'relative' to the protocol being used, etc.

[Rauven]

I'm not discounting what you say. Your HTML knowledge is likely greater than mine as my HTML skills have completely oxidized, but from what I can see looking at the source for the archived versions of both the LOTRO and DDO stores the stylesheet href links all have https:, the store CSS file does too, as well as the correct & character code in the links. The current live versions of both stores and the CSS file all lack the preceding https: and have ampersands instead of the proper character code. To me it appears to be a combination of problems.

[DYWYPI]

The 'Internet Archive' possibly added [https:] to the HTML source code for the specific CSS file link we are most interested in, i.e. https://drh.img.digitalriver.com/sto...File=style.css.

Those 'absolute' links to the CSS using LINK beginning: "https://" isn't the (main) issue. Even though the ampersands shouldn't really be written how they currently have them (as explained prior) as it can cause breakage.

[...] To me it appears to be a combination of problems. ...

We've deduced it's not the Firefox browser at fault. Plus I suspect; we'd be both in agreement with having the links to the CSS starting "https://" rather than "//" is best practice. :-)

I agree it looks like there is more going on rather than just sloppy HTML syntax, e.g. faulty Server or CMS configuration.

AFAIK the server itself has to be specially setup for it to use that form initially starting "//" and serve both HTTP and HTTPS assets simultaneously.

Essentially how they currently have it setup (links to the [none HTTPS] CSS and URL references with the CSS) for the 'DDO Market' is totally "anti-pattern"; a commonly reinvented but bad solution to a problem. :-(

There isn't any sensible reason for them to be using those "network-path reference" for the LINK element starting "//" whatsoever, full stop!

Let alone the security aspect of being weak against 'Man-on-the-side attack' by using that idiotic anti-pattern method.

The 'DDO Market' is already served as HTTPS. Even if some of the content was HTTP it'd be still completely safe writing "https://" for the link to the CSS file(s) in question.

Note: modern browsers can also be set to automatically block mix mode content due to such potential security issues.

Standing Stone Games, I'd STRONGLY recommend you help resolve the issue by using best practice HTTPS for the CSS file links. Partially due to the security issues and it being considered bad practice using the "network-path reference", i.e. "//" to link to the CSS files. It will also likely result in the page rendering correctly in Firefox again.

[Rauven]

Standing Stone Games, I'd STRONGLY recommend you help resolve the issue by using best practice HTTPS for the CSS file links. Partially due to the security issues and it being considered bad practice using the "network-path reference", i.e. "//" to link to the CSS files. It will also likely result in the page rendering correctly in Firefox again.

Agreed. Regardless of what we can deduce or sleuth out the issue has to be resolved on their end. SSG, please take a look at this because right now, and for some time (read over a year) the web stores for both LOTRO and DDO have been broken and unusable.

[DYWYPI]

Conclusion: Basically Firefox is CORRECTLY Content Blocking "mixed mode" Content! :D

It is not a rendering issue; it fully understands the "//" but what the 'DDO Market' is doing is a both a SECURITY risk and BAD PRACTICE, i.e. trying to simultaneously send CSS assets (and some other assets) via HTTP and HTTPS!

If you open the Firefox Web Developer Console; you will see that it has correctly "flagged" the CSS to be blocked. Note: we're assuming your browser has been set; to Protect you against 'threats' from "mix mode" content and malicious websites, and advanced tracking, etc.

Firefox: to open the Web Console: select "Web Console" from the Web Developer submenu in the Firefox Menu.

Bad Anti-pattern practice in action.

You'll see similar to above the image; the "red coloured: 2" refers to the fact there are actually two versions of the same file trying to be sent twice, one file via HTTP and one via HTTPS... Yes, it's a security threat issue and very bad practice to boot.

Anyone who is seeing 'DDO Market' render that CSS in their own version of Firefox likely has Mixed Mode Protection completely DISABLED or low security settings. For example the within; about:config, setting [security.mixed_content.block_active_content] flag to FALSE, will ALLOW potentially dangerous mixed mode content.

The same probably applies to the Chrome Browser, albeit I don't have access to that browser.
https://support.google.com/chrome/an...605892405&rd=1

So I'll reiterate my advice from my previous post regarding recommending SSG help resolve the issue by using best practice HTTPS for the CSS file links. :-)

[Rauven]

Conclusion: Basically Firefox is CORRECTLY Content Blocking "mixed mode" Content!

You're right. As soon as I toggle off "Enhanced Tracking Protection" in the security settings for the page it completely loads.

ETA: With Enhanced Tracking Protection set to Strict the store won't load. With the Default setting the store will load. The setting difference is that Strict blocks all tracking content in all windows whereas Default does that only for Private windows.

[DYWYPI]

Strange times indeed the threat of the Pestilence tends to be semi-distracting. My brain must have completely malfunctioned and was totally switched off... It should have occurred to me by the time; I posted the Internet Archive version [Post #11]. I should have taken a look what the browser was doing with regards to the server. As the few links using the absolute "https://" weren't malformed - I'm kicking myself LOL.

Basically it "//" is the kind of linking method that unfortunately was encouraged by some shady advertising organisations over 10 years ago to slip aggressive third-party "trackers" under the radar. Sloppy CMS coding I believe in some cases will do that same type of linking. For example when they cut corners and thus spit out far too many multiple slashes "/" in the wrong places, etc.

Even in 2005, it was considered poor practice using that linking method for obvious reasons. Its left up to the Browser to negotiate, very inefficient and a potential security risk.

I would suspect some of the Firefox "auto blocking" triggers are because of the already dubious common "fingerprinting" cookies being present on that site.

In contrast if I upload a generic plain HTML file to my own server and link using "//" method and deliver mixed mode it via SSL, it likely wouldn't be blocked by most standard Firefox configurations. Plus display correctly since I have integrity and won't be running additional unnecessary scripts, etc.


Aside: I don't work in Information Technology and Communication and never have. Although I have had numerous major Web Developer forums try head hunting me for Moderating positions in the past. I have also judged a handful of HTML Competitions, which had a web master from; Yahoo, actual Browser Software Developers and someone that applied for NASA compete, and people that had written Books on CSS competing - so an interesting mix for me to judge. So I'm pretty solid with markup semantics, but nothing special. I've even wrote a Chapter on TCP/IP for published book. I wouldn't worry, if your HTML is "rusty" since you actually bothered and cared enough to investigate and that is worth its weight in gold. :-)

An ant on the move does more than a dozing ox. :D