So I downloaded a MathJax package, unpacked it, modified the settings and uploaded the files to an http domain. Everything worked as well as possible for more than a year.
Two days ago, I copied all files (including the database) to a new domain, activated SSL and modified .htaccess to translate all addresses into https. This works perfectly for everything except MathJax "Can't load web font" resulting in a 10 second delay every time it attempts to draw expressions.
Neither Firefox nor Chrome show any kind of errors in the console or failed file reads (cache off, 200 OK). The only effect in the browsers is that there is a 9-10 second gap between /mathjax/jax/output/HTML-CSS/fonts/STIX-Web/Main/Regular/Main.js and /mathjax/jax/output/HTML-CSS/fonts/STIX-Web/Main/Italic/Main.js.
Approximate timeline …
2 s: read (success) /mathjax/jax/output/HTML-CSS/fonts/STIX-Web/Main/Regular/Main.js
11.5 s: read (success) /mathjax/jax/output/HTML-CSS/fonts/STIX-Web/Main/Italic/Main.js
12 s: read (success) /mathjax/fonts/HTML-CSS/STIX-Web/woff/STIXMathJax_Main-Regular.woff
Log (last 4 lines) …
Loading [MathJax]/jax/output/HTML-CSS/fonts/STIX-Web/Main/Regular/Main.js
Loading web-font STIX-Web/Main/Regular
Can't load web font STIX-Web/Main/Regular
Loading [MathJax]/jax/output/HTML-CSS/fonts/STIX-Web/Main/Italic/Main.js
In the timeline, the seconds are the timestamps of the attempts, not the durations. Those are 0-100 ms each.
What I have tried:
Reset .htaccess, loaded everything with http, recopied all MathJax files from old domain to the new one and made sure all directories and files have the proper permissions. I have also entered the paths (in the address bar) to the failing woff files and they download properly. Furthermore, I have disabled SSL and modified the script tags to read the settings file and MathJax from the old domain – still a 10 second delay before attempting to read font files.
How can I tell why MathJax can't load a web font? Why does MathJax, with identical code, add a delay on one site but not the other? Is there a way to troubleshoot this?
Update:
This is now really weird!! After cross-loading files between the sites, I have narrowed down the error to be connected to my CSS file!… which passes validation perfectly (and contains no font changes, between sites, at all). The main change I've done in that file is to add wrapping divs to most elements directly inside body in order to style the wrappers at 100% width, but have the content at 80%.
It turns out that MathJax (2.6.0 and 2.7.2) failed to load a font because I set a min-width on #MathJax_Font_Test. I did not do this on purpose and had no idea it would break. Here's my fix:
body > div > div:not(#MathJax_Font_Test) {
min-width: 960px;
}
Related
On my TYPO3 v10 website I have some SVG icons in use, no problem.
I also have a few more complex SVG Figures (created with Inkscape), that I want to include in TYPO3 website. Of course I can upload the .svg files to the fileadmin/ folder, and link to them with the Text+Image (or Text+Media) Content Elements.
In the Backend, TYPO3 generates some fine png-thumbnails for preview. So far so good.
The file can be downloaded directly, from its fileadmin/images ... location.
However, inside web pages, my SVGs are not displayed as they should.
A lot of styling information gets removed from the SVG and I don't know where.
Here is a screenshot of the original vs corrupted image (as displayed in the TYPO3 frontend).
Here is a graphical diff that shows the difference between the figures.
It turns out that at some time during the rendering process, TYPO3 removes the values from the style="...." SVG attributes. See reddish boxes.
All my more complex SVGs look like the one on the right when embedded in TYPO3.
Here is the SVG if you want to try yourself: image on SVGshare.com
On the right, many style attributes have been set to style="".
but why?
It's Firefox, not TYPO3, who removes the style="..." attribute values. This seems to be a longstanding Firefox Issue, solved.
See Bugzilla Issue 1262842: [CSP] Blocks the use of style attributes inside SVG without generating console errors.
Look for "triply confusing" in the first comment.
Inline CSS styles can be a security Problem, and therefore Firefox has a Content-Security-Policy (CSP) in place, in order to correct this.
An explainer for the mitigation strategies, written jointly by professional Security Engineers is given in this Google Doc and in Gihub Repo (Content Security Policy), Issue 45, Further granularity of unsafe-inline styles.
Script inline attributes are a difficult subject to approach when it
comes to CSP, they have the same amount of power as any other script
element but they don’t have ways to be whitelisted, for example, by a
nonce or hash. This means that the actual content of the attribute is
mostly the only deciding factor.
I don't understand everything mentioned in these docs and discussions. Inline-style Elements seem to be vulnerable to XSS attacks, and then attacker can put CSS url() in there for instance.
Quick-and-dirty solution
Use Inkscape and save as "optimized SVG", and check the option "Convert CSS Attributes to XML attributes". See attached screenshot of the Inkscape Dialog (Linux).
This solution was proposed by a web-developer from the GIMP devteam.
TYPO3 9 introduced an SVG Sanitizer, which automatically modifies SVG files during "fileadmin upload time", meaning it removes any <style ...> elements from the uploaded SVG file.
In TYPO3 10 and later versions, this SVG Sanitizer is by default automatically set up via Symfony dependency injection via core's Services.yaml.
You can remove the SVG Sanitizer via your own site extension's Services.yaml, e.g. for your myextension/Configuration/Services.yaml:
services:
_defaults:
autowire: true
autoconfigure: true
public: false
# ...
# remove TYPO3's default-autowired SvgSanitizer, which tampers with filadmin uploaded SVGs (e.g. removes necessary <style> information)'
TYPO3\CMS\Core\Resource\Security\SvgEventListener: ~
The tilde (~) removes/overwrites the definition previously set up by core's Services.yaml ( https://symfony.com/doc/current/service_container/service_decoration.html ).
This seems to be a problem of your individual TYPO3 installation. I've just tested your SVG image in a brand new TYPO3 v10 installation and the image is rendered properly in backend and frontend.
Maybe you have some 3rd party extensions installed who postprocess the HTML output of TYPO3, e.g EXT:sourceopt or EXT:scriptmerger.
Not sure if this is an Edge or more general Windows 10 question, but trying to get pinned site tile to work I'm encountering some rather strange behavior.
First of all, are application tile images cached aggressively? It seems that once a site was pinned, changes to the relevant meta elements seem to be ignored. Un-pinning, clearing browser cache and doing a Windows clean-up of temp files/temp internet files has no effect. Even completely removing the meta elements, then trying to pin the site, still reuses the old ones. This makes debugging/testing rather difficult. Is there something I'm missing? How can the tile information be flushed?
Secondly, it seems that the specified msapplication-TileColor is not handled correctly - in the example below I'm using transparent PNG files for the icons themselves, setting a tile color
<meta name="application-name" content="The Paciello Group (TPG)">
<meta name="msapplication-TileColor" content="#1b75bc">
<meta name="msapplication-TileImage" content="/images/tpg-white-trans-144.png">
<meta name="msapplication-square70x70logo" content="/images/tpg-white-trans-70.png">
<meta name="msapplication-square150x150logo" content="/images/tpg-white-trans-150.png">
<meta name="msapplication-square310x310logo" content="/images/tpg-white-trans-310.png">
However, checking the color that's actually used, it seems to be closer to #2672EC than #1b75bc. Could this be because of some color profile issue? Could it be that color profile information in the PNG is affecting the rendering of the actual specific tile color?
They messed up, first Windows 10 release it was taking msapplication-tilecolor, after first mass update around 5th of August, they took away tilecolor as well, made it default blue (or whatever user preferences are)
We also need text color as well
First of all, are application tile images cached aggressively?
Yes, remote tile images are cached, and they're cached separately from the normal internet cache. To update an image without changing the URL, you have to add a new query string parameter, so that it's considered a new URL.
How can the tile information be flushed?
The cached entries are stored in the registry at...
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\PushNotifications\wpnidm
You probably can find the related image cache entry and delete it for debugging purposes, but I won't make any promises.
Secondly, it seems that specified msapplication-TileColor is not handled correctly
Looks like SiSL has your answer for that: "They messed up, first Windows 10 release it was taking msapplication-tilecolor, after first mass update around 5th of August, they took away tilecolor as well, made it default blue (or whatever user preferences are)"
I found the cache path!
Go to a path similar to this: "C:\Users\UserName\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\LocalState\PinnedTiles".
The folder "Microsoft.MicrosoftEdge_8wekyb3d8bbwe" might have a bit different name.
The cached files (Images, XML...) of the tiles you pinned will be inside the folders in this path.
Delete as much as you want.
I am not sure this is about the color, though. I've been testing this MSTiles feature recently and it looks like on Win10 it now uses one of the icons you set for the website (for me it seems to utilize largest icon from webmanifest). It completely ignores what I write in metatags of browserconfig.xml file for icons, as well (square* and wide* elements), which seems to result in the fact I can only set tile's size to small or medium.
I'm using Bootstrap files within my application and I want to enable "Use runtime optimized JavaScript and CSS resources".
the problem I have is once enabled; glyphicons-halflings-regular.eot, glyphicons-halflings-regular.svg and glyphicons-halflings-regular.woff cannot be found:
I know for Bootstrap 2.3 we could use a Theme that loads a .CSS file that changes relative locations as described here http://www.bootstrap4xpages.com/bs4xp/site.nsf/article.xsp?documentId=F435B6DC54486B67C1257B6B002E5A6C&action=openDocument
So, what should I do to handle relative locations with Bootstrap 3?
You have to tweak the path to the web font resoureces in the Bootstrap CSS files.
Delete the part with "../" and replace it with the relative path to the font files within your project structure, e.g.
bootstrap/fonts/...
Then aggregation will load the fonts correctly.
This does not answer your question but if you want to use Bootstrap 3 you'd be MUCH better off using the Boostrap4Xpages project on OpenNTF.org. It will perform better and the resource aggregation will work better. It's easy to install and use but it is a plugin on the sever so that needs to be done. It's not self contained to the NSF. Try and move to this if at all possible.
Regarding the actual question. I'm not sure I know the answer specifically. I do know that using relative links can sometimes be a problem if the browser's URL doesn't have the page.xsp portion. So it works on the page.xsp and NOT the default launch XPage where the URL ends with the database.nsf. What I've done in the past there is set the application to launch to something like "start.xsp" and in that page in beforePageLoad to a redirect to "home.xsp". This forces the browser url to always show the page name and made life a little easier when dealing with adding projects to WebContent.
I just started trying out the TideSDK to deploy a website to .exe and .app, which for the most part is fantastic.
The problem that I'm currently coming across is that all my CSS styles are written in .less styles utilizing the less.js framework. Inside of here, I have custom font-faces declared, and when deployed to a standard web browser, they apply fine to all the elements that use them.
When deployed through Tide, it doesn't seem to stick unless I take all my styling out of .less style sheets and put them back into regular .CSS files, which leads me to believe that there is some sort of compile time change that Tide is using internally when deployed the actual view of the application.
I have no idea how to go about fixing this. As a note, I'm not getting any
[Error] Error finding
errors from the Tide console, which leads me to believe that the .svg's are being found, just not applied.
UPDATE:
It seems I was using wrong syntax in the src: url('...'), so the CSS in the .less file was actually failing silently. I'm getting a pretty strange [Error] Error finding... file for the .svg now. The URL that is inside this line of CSS is being prepended by app: 3 times.
After several hours of looking at this problem, I eventually have figured it out. Couple of things to note when you are using the combination of these frameworks:
less.js spits out really odd path directories when using
src: url('...');
As a solution for this, you can use the import directive that is available to you in less and put the #font-face declarations inside of that .css style sheet. By importing a plain .css style sheet, you are telling less.js to treat it as regular .css, and the muxed url that gets spit out won't happen.
#import "../css/style.css";
After putting the import directive and confirming that the SVG was indeed being generated under Resources - Fonts in the Chrome inspector, I proceeded to take a look at the SVG file itself to determine if there was something wrong in the CSS naming conventions for the SVG file. According to this answer, and the blog post within it, your SVG name should be using:
font-family
value in the naming scheme from the SVG meta data
src: url('YourSVGFont.svg#Silkscreen') format('svg');
when in fact, you should be using the font id, at least that was the solution in my case:
src: url('YourSVGFont.svg#slkscrb') format('svg');
This is the image embedded in the blog post so that you can see what I'm talking about, and see where in the SVG meta data these two names are placed.
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?