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.
Related
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.
I just encountered a strange behaviour in my current RoR web app: every time I use the browser's back button (multiple browsers tested, safe mode included), the GET request is being sent multiple times, duplicated. Sometimes twice, but up to 5 times in a row in under 3 seconds. This also causes the SQL queries to run multiple times, doing the same thing.
If I use links to go back, or paste URLs to access the previous page, this does not happen.
Did anyone encounter this, or know what could cause it?
Thanks for your help!
Best,
Alex
Although I've found this to be caused by other issues, the main cuprit is Turbolinks.
Basically, Turbolinks loads the body of your new view via ajax, instead of pulling the whole page (it's meant to speed up the application in production).
It's often the case that Turbolinks will cause issues such as duplicate requests when pressing the back button etc... although to get it with every browser is very strange.
--
Due to a lack of code, I can only speculate on this issue.
It's probably wrong, but a good test to see if it replicates is to remove the references to turbolinks in your JS files; specifically:
#app/assets/javascripts/application.js
//= require turbolinks <- remove this line and see if it fixes the issue
I'll happily delete the answer if it's inappropriate. You'd be best putting up a public repo so that people can see what infrastructure you have.
For me, I realised that the issue was caused by javascript_include_tag out of head tag in aplication.html.erb.
After moving to correct place (inside head tag, right after stylesheet_link_tag) the multiple requests was gone!
I've not found any other resources on this issue, so I figured I would ask the SO community. :)
I currently have an issue with my CFB2 client going into a memory leak about three seconds after I edit a particular file on one of our company webservers. This also occurs when I try and edit a local copy of the file. The leak is slow and would take many many hours to hold up all of my free RAM (~6.5GB/8GB physical). There is also a high CPU usage on the leak (anywhere from 25-45% | 1.8 GHz four-core). The only visual feedback I receive is in the Outline pane, where it extends infinitely into a loop of cfelseif tags. The pane also holds the loop before editing, but does not attempt to extend it.
This error first occurred whilst I was creating a cffile tag and because I could not close it, the conditional statements were mis-highlighted. I believe this is the root cause of the issue, however, I do not know why this occurred.
As I complete typing of this, I will move the file to a simple editor, remove the line that caused the error, and attempt to add it again, however I fear that the addition of the line will end in the same manner.
EDIT: I moved the page source into Notepad and removed the pesky cffile line. Then, I proceeded to delete the file from the webserver, create a new file of the same name, and add the code back. I closed the tag before adding any attributes just to ensure the same issue would not occur, and it did not experience the same loop.
In my project I use jCarousel (http://sorgalla.com/jcarousel/) plugin to dynamically display images and list them.
I wonder is anybode expirienced memory problems with this plugin?
I'm trying the following scenario:
Configure jCarousel to dynamically load images
periodically reset jCarousel and load new images
As the result IE requires more and more memory that is not cleaned by GC.
In sIEve I can see that elements used by jCarousel (eved removed) are still used by somebody, but unfortunately I can't see see who is referencing on the node. The node is not marked as leak.
Remove the parent container's style "overflow:hidden;", you will find out what's going on.
When "warp" is set to "circular", and autoscrolling proceed, jCarousel will copy entire nodes each time it scrolled, and never removed.
Sorry for that I'm searching for solution either. Wish you have solved the problem.
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.