How to debug why MS Edge/IE11 does not load sourcemap - microsoft-edge

I made some source+map concatenation and result works in Firefox and Chrome, but does not even request bundle.js.map from webserver in MS Edge and IE11.
Actual JS file is served from http://localhost:8080/bundle.js
bundle.js ends with line:
//# sourceMappingURL=bundle.js.map
Tried both end it with new line and without, does not work in both cases. Is there some checklist to look at or even some "validator"?


Microsoft Edge expects a single sourcemap comment, located at the end of the file. Your file contains two comments, which appears to cause the issue. Remove all but the final comment, and this should resolve the issue for you.
I will file a ticket to track this issue, but it's unlikely we will modify our implementation to accommodate a non-standard use of sourcemap comments. Thank you for bringing this to our attention though. We'll keep watch to see if this affects other users.

Related

The file cached by the service worker is smaller than the original one

I am using a service-worker to cache javascript files. It is written using Workbox.
I ran into a problem that after the browser takes the cached file for execution, it is 3 bytes smaller than the original one - at some point, three spaces disappear from it, due to the absence of which the code turns out to be broken.
Three occurrences of the code 0 .toFixed() (this is a valid construct that my minifier made) have a space removed, due to which it turned into an invalid construct 0.toFixed(). It's like an additional (broken) minifier appears in the caching process.
What could be the reason?
I tried to check if Workbox is the culprit. I wrote a simple worker without it. The problem is gone. But since then I haven't been able to reproduce it at all, even going back to the original code, so I'm stumped and can't analyze the problem myself.

How do I use #{request.contextPath} when the context root is, well, root: "/"?

We are currently moving an EE6 / JSF application from a deployment path someserver.com/app to its own subdomain app.someserver.com.
Most things are working smoothly, but we have had unexpected troubles with how the web layer handles the now basically nonexistent context-root.
One thing we found and fixed early was that a cookie we set had its path shortened from "/app" to "", and thus was only readable per folder on the server, not for the entire application.
We have now found a similar problem with hyperlinks that we generate in JSF:
Go to home page
This was previously rendered as href="/app" and worked fine, but now with href="" the link is understandably no longer active. I want it to say href=""/".
Is there an elegant solution for that?
Keep in mind that we also have links of the form
Go to projects page
, so simply replacing the empty context path with "/" is not good enough.
Am I missing something obvious? I saw an explanation here (which matches what we experience), but no elaboration on possible solutions.

Turns out I wasn't thinking clearly. I was so focused on fixing the string that #{request.contextPath} produces, that I missed that I basically used it wrong the entire time.
The simplest solution is to just use
...
(with a trailing slash) to get to the root of the application, and never use href="#{request.contextPath}" without a slash at all.
This solves both cases. If the application is deployed to "some_folder", the link becomes "some_folder/". And if the application is deployed to the server root, then the link becomes "/".
Hope this helps someone who stumbled into the same trap.

Running graphgists locally fails

I'm interested in running a graphgist locally, for which there is a script here:
https://gist.github.com/jexp/70296ce410ff431ddbef
I was able to install the modules and run the two tasks but the last line of the script:
open http://localhost:8000/?http%3A%2F%2Flocalhost%3A8000%2Fgists%2Fmy-graph-use-case.adoc
produces an error: Not Found and trying to open the link in the comments:
http://localhost:8000/gists/my-graph-use-case.adoc
causes my browser to download a file for which I have no associated application. has anyone made this work and if so, how?

according to #MichaelHunger the issue is that the default behaviour in Python's SimpleHTTPServer is such that a trailing slash (/) gets added to the end of the url, messing up the request.
according to #PratikMandrekar, in the following article, the problem is that the url as it is in the script does not explicitly specify the file name, forcing the server to redirect to the default. see:
Why does SimpleHTTPServer redirect to ?querystring/ when I request ?querystring?
so after a little experimentation I found this to work:
http://localhost:8000/index.html?http%3A%2F%2Flocalhost%3A8000%2Fgists%2Fmy-graph-use-case.adoc
notice that the colons, slashes, etc. in the inner url must be encoded for this to work

There is a bug/default behavior in simple-http-client that makes it add slashes after query parameters which breaks our app in this case, I have to find a better replacement or fix it.
Perhaps I can also change the rabbithole project to server the graphgist files itself, so that it would be self-contained.

How to use component from the old indy9 package

I have upgraded Indy9 to Indy10 in Delphi7. Took some time for me to change all the parts with TCP servers and clients but seems like it works nice now.
Now, i noticed one part is still not working, and thats idHTTPserver component.
Our applications web page is using a mootools library. With Indy9 idHTTPserver it works perfectly, however Indy10 does something, which makes browsers fail to display the page.
Besides some other errors, there is this nonsense error like (Firefox Error console output):
Timestamp: 2013.08.07 13:13:56
Error: SyntaxError: missing ] after element list
Source File: http://192.168.100.2:8780/lib/ui/core/mootools-1.2.4-more-yc.js
Line: 103, Column: 60
Source Code:
unction(){var b=["C?","C ","C","C?","C,","C¢","Cƒ","C£","C"","C¤","C.","C?","Ä,","ă","Ä"","Ä.","Ä?","Ä?","ÄŒ","Ĩ","C?
-------------------------------------------------------------^
The actual source code inside this .js is:
long long text ....... function(){var b=["C?","C ","C","C?","C,","C¢","Cƒ","C£","C"","C¤","C.","C?","Ä,","ă","Ä"","Ä.","Ä?","Ä?","ÄŒ","Ĩ","C?","C§","Ä?","ĸ","Ä","Ä'","Cˆ","CØ","C?","C©","CŠ","CR","C<","C«","Äš","Ä>","Ę","ÄT","Ä?","ÄŸ","CŒ","C¬","C¨","C­","C?","C®","C¸","CÆ","Ĺ","Är","Ľ","ľ","Å","Å,","C'","C±","Å?","ň","Ń","Å"","C'","C²","C"","C³","C"","C´","C.","Cµ","C-","C¶","C˜","Cø","Å'","Ř","ÅT","Å"","Å.","Å ","Å?","Å?","ÅŸ","Åš","Å>","Ť","Å?","Ť","Å?","Å¢","Å£","CT","C¹","Cš","Cr","C>","C»","Cœ","C¼","Å®","ÅÆ","Åø","Cæ","C½","C¯","Ž","ž","Ź","År","Å»","ż","C?","C¾","C","C°","CŸ","Å'","Å"","C?","C¦","Aµ"]; ................ long long text
What is happening here?
I took a deep breathe and thought, hey i could just use the old version of idHTTPserver as i still have the source files of Indy9 in the other folder.
If nobody knows how to fix the indy10 HTTPserver, could somebody please tell me how do i use the old version? Just the HTTPserver component (which surely links with 10s of other old indy files).
I tried to include the old sources, but it was becoming a mess, because it would use the idHTTPserver.pas from old version, yet idCustomHTTPserver.pas (this is what happens after i follow the uses of idHTTPserver.pas file) from new version...

To use a different Indy version in one project, set the project search path to Indy\Lib\Core, \Protocols and \System, and instantiate all components in code.
This also has the advantage that you can avoid the uninstall / install steps to switch between different Indy 10 versions.

While this is not the direct answer to my own question in title, this did solve my problem.
I followed the function HTTPserver.WriteContent which led into idHTTPServer.pas, then compared idHTTPServer.pas files of Indy9 and Indy10, the parts about encoding in Indy10 caught my attention.
At line 2039 i have removed the second argument of the write function
FConnection.IOHandler.Write(ContentText, CharsetToEncoding(CharSet));
replaced with
FConnection.IOHandler.Write(ContentText);
This solved my problem. Everything works fine now.
The main problem here was, as commenters have noticed, the extra " symbols.
I was quite stupid because i clicked the link in the firefox console and it opened the javascript file which was of wrong version and for some reason i thought this was what it was supposed to be. Only a bit later i decided to check the actual file on my PC and it turned out that "C"" was not even C, the actual text is this
var b=["À","à","Á","á","Â","â","Ã","ã","Ä","ä","Å","å","Ă","ă","Ą","ą","Ć","ć","Č","č","Ç","ç","Ď","ď","Đ","đ","È","è","É","é","Ê","ê","Ë","ë","Ě","ě","Ę","ę","Ğ","ğ","Ì","ì","Í","í","Î","î","Ï","ï","Ĺ","ĺ","Ľ","ľ","Ł","ł","Ñ","ñ","Ň","ň","Ń","ń","Ò","ò","Ó","ó","Ô","ô","Õ","õ","Ö","ö","Ø","ø","ő","Ř","ř","Ŕ","ŕ","Š","š","Ş","ş","Ś","ś","Ť","ť","Ť","ť","Ţ","ţ","Ù","ù","Ú","ú","Û","û","Ü","ü","Ů","ů","Ÿ","ÿ","ý","Ý","Ž","ž","Ź","ź","Ż","ż","Þ","þ","Ð","ð","ß","Œ","œ","Æ","æ","µ"];
So, i was right. When the whole text goes through CharsetToEncoding, it translates all these single symbol characters into 2 symbols.
I will not accept my own answer as it doesnt really answer the title question and i would love to know if its possible to use a single component of older version while the rest are newer.

Why does my CSS go screwy "sometimes"

A website of mine is behaving weirdly. The layout sometimes is fine, and sometimes it is screwy. An example page that I see the problem on is this one: link
Disclaimer: I have yet to start my investigation into cause in earnest. I am turning to Stackoverflow because I am lazy and I hope someone will say "That happened to me once, it is probably this...". So please, no one get stuck into this working out this issue if it is something you have never seen before, as it wouldn't be fair as I have not done it myself.
Ok, some background:
The problem usually (maybe always) occurs when first viewing the page
The problem does not show up always, only sometimes
When the page shows up munged, if you refresh it usually reloads looking as it should
The site is a rails app
The css is passed through the neat Smurf Gem, which automatically minifies the CSS and Javascript on the page.
The layout problems happen in firefox (both linux and winXP)
The CSS is served up in the production environment using the ":cache => true" option which concatenates all the css files into one file
Anyway, I am hoping that this has happened to someone before and it will be really simple to fix. If not, I'll go and investigate and return with the solution (or a request for more help).
Thanks in advance!
James.
[edit]I added the first two bullet points, inspired by the comments and first answer[/edit]

We have had something similar when using HAML and SASS that resulted in the CSS being completely unavailable. It only happened on deploys. We determined it was a combination of the Rails stylesheet merging and the generation of the CSS from SASS. Sass was not done generating the CSS, which it did so on the first request to the application, when Rails attempted to merge it all together. The result, a corrupt useless CSS file. Then we stumbled upon this article which has a solution for preventing this issue.
Based on all this, my best guess is that the Smurf gem is attempting to generate your file on the first request, but Rails is serving it out before its done. The generation completes then each following request is fine. If this is the problem then the only solution i know of is to get the file generated before the first request. Of course, this does assume that it is related to deployments or application restarts in some way.
Peer

I had such a problem. The problem was only at the first time the page was loaded. Just reload it and it was fine.
The problem in my case was that the images where not there in the cache for the first time so the browser didnt know it's dimensions when preparing the page which caused the problem

If an image doesn't have a height/width assigned to it, a place is created on the page and it's put there. If the image doesn't quite fit, the browser may not know this until it's refreshed. Then it already knows the size and can properly fit it onto the page.

Resources