I have a 1-year-old React app with Server Render that had been in production for a while,
However, it was detected a couple of days before that somehow, the app stop to work with IE11. This is really weird because we have been tested on IE11 many times and it worked before. We even try to roll back the project (using tagged docker image) and this error still appears.
The root cause appears to be in babel-polyfill that somehow change the way Object is created in IE11.
The created object will have jscomp_symbol_Symbol.toStringTag1" Array Iterator"
Here's what I found on the console:
try this input console.log({}) if you have IE11 it will output differently.
This somehow causing my web app to fail since every object will fail lodash _.isPlainObject which is the condition inside Redux.
Related
The warning:
(process:3380): GLib-GIO-WARNING **: 12:47:10.778: Unexpectedly, UWP app `HaukeGtze.NotepadEditor_1.795.1.0_x64__6bk20wvc8rfx2' (AUMId `HaukeGtze.NotepadEditor_6bk20wvc8rfx2!notepad') supports 182 extensions but has no verbs
I think the part before the word 'Unexpectedly' is the time, but what does the rest mean?
The last thing I was doing before this started was installing canvas with npm install canvas --save.
So is there a way for me to stop this?
I also noticed it says NotepadEditor there but what does that have to do with anything? It doesn't crash the process, and doesn't seem to affect anything, but it's annoying.
EDIT : it was caused by require('canvas') rather than installing it. So how can I require it without getting the warning?
I encountered similar problem but with "Microsoft.Print3D" and "Microsoft.DesktopAppInstaller" instead.
The cause:
IDK xD. It does say in the https://github.com/frida/glib/blob/master/gio/gwin32appinfo.c#L3477 niry posted before, that:
...for 100% correct handling we (GLib and GIO) need to remember which extensions
(handlers) support which verbs, and each handler gets its own copy of
the verb object, since our design is handler-centric, not
verb-centric. The app also gets a list of verbs, but without handlers
it would have no idea which verbs can be used with which extensions.
As of why it has no verbs, I suspect it has something to do with registers and installation due to the solution I provided below.
My Solution: Reinstalling the problematic app
Before you begin, this only fixed my problem with Print3D and made the problem with DesktopAppInstaller worse; it now says "Failed to open manifest..." and I had to reinstall it, which also removes the problem with canvas.
Run Powershell with Administrator privilege
Get-AppXPackage "HaukeGtze.NotepadEditor" -allusers
If it exists, jump to number 4.
or
Get-AppXPackage -allusers
Find the problematic one (HaukeGtze.NotepadEditor) and note the NAME (not the package full name).
Get-AppXPackage [name here] -allusers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
I had the same problem when using Python weasyprint package. It was complaining about Windows PDF X app. GLib-GIO-WARNING **: 11:31:57.620: Unexpectedly, UWP app `6760NGPDFLab.PDFX_1.3.13.0_x64__sbe4t8mqwq93a'. I simply uninstalled the app and the problem went away.
I have a React app that recently starting emitting this error.
https://reactjs.org/docs/error-decoder.html?invariant=94&args[]=onClick&args[]=string
Minified React error #94:
Expected onClick listener to be a function, instead got type string
When this error appears, none of our buttons/dropdowns work but the webpage isn't frozen. It only happens in one section of the app. When we navigate to another section and come back, the error does NOT appear again.
I've gone over every single onClick event in our app and there's not a single function that could possibly be passed in as a string or can be returned as a string. Although we have a few onClick events that can be passed a NULL object.
But we've narrowed down the steps that produced this bug:
It only started occurring when we updated to Chrome version 65, which only came out 2 days ago. The bug does NOT happen in previous Chrome versions (before v65)
It only happens in our production build of the React app, not on localhost (could it be a minifying error?)
The bug doesn't happen in our other apps, also built with React and minified with similar webpack configurations.
Does anyone have an idea of why this error is happening and how we can solve it?
Turns out it's specifically the minified/production build of React that's incompatible with Chrome65.
We flipped process.env.NODE_ENV back to 'development', until we find a better solution, or Chrome resolves the issue with v65.
Update: If you are using the toJS() HOC from redux (https://github.com/reactjs/redux/blob/master/docs/recipes/UsingImmutableJS.md#use-a-higher-order-component-to-convert-your-smart-components-immutablejs-props-to-your-dumb-components-javascript-props), the problem is with Object.entries().
To fix this for now, replace Object.entries with a custom entries function:
(ES6)
const entries = x => Object.keys(x).reduce((y, z) => y.push([z, x[z]]) && y, []);
You should be able to flip your NODE_ENV back to 'production'.
Currently trying to figure out why the wrappedComponentProps object causes the issue, but a regular object like { myFunc: function(){} } doesn't.
(Any help debugging this would be appreciated!)
Calling delete wrapperComponentProps[ANY-VALID-KEY] before running Object.entries() fixes the issue, so I suspect it's something to do with object security/caching.
I found a solution. I still think there was an error with Chrome v 65's minification process but I started deleting clickable components from my app until the error was gone to flush out the problematic component.
Turns out it was a <LinkContainer /> from react-bootstrap-router library that was causing the bug. We replaced with react-router link components and the error went away!
Safari isn't rendering my single page application built in VueJS.
I have spent 2 weeks developing it. It contains components that show or not depending on user clicks. And data objects that are rendered via the "v-for" element.
In chrome all works perfectly!! In mozilla also...in safari the list doesn't show up. Why isn't safari rendering anything?? I can't even debug it..
I looked up work arounds, like polyfills...but these seem to not be supported by safari..so there's no point in implementing them.
Would love some support or insights guys..if there's no work around does that mean i have to go back a build it in JS + Jquery?
Thanks in advance
So, I had this same issue. Meaning, a series of components listed with a v-for but not rendered on the screen (or the DOM) only in Safari (on Mac) even though it worked just fine on Firefox and Chrome (even on Mac). And after long and hard attempts, I was able to resolve the issue. I will give the answer in two parts.
THE QUICK ANSWER
In my case, the render error was the end result of a date conversion gone wrong somewhere deep in my code in a helper file. Indeed, in this file, I was receiving an ISO date in string format and transforming it into a JS date object through new Date(myISODateString). While Firefox and Chrome handle this conversion just fine, Safari was producing 'Invalid Date' errors and the chain-reaction was only effecting a single component. Once I corrected this date parsing, everything was being rendered correctly in Safari. In this instance, I used Luxon to do the conversion, I will give that as the solution
DateTime.fromISO(myISODateString, { setZone: true }).toJSDate();
THE LONG ANSWER
I think what is even more valuable in this experience is how I found out that this was the problem since in your case, it will probably be some other particularity of Safari that is causing the error.
It was actually Frank Provost's comment on this question that guided me in the right direction.
It goes without saying that smaller components are most of the time constructed from their props. It is like their life source. If props are erroneous, internal operations and render will also be problematic.
So I decided to console, within the lifecycle hooks, the props that my non-rendering component was receiving. Of course, nothing was printed out to the console. So I went up one level above and did the same thing for the props of the parent component. This time, I was getting information in the console but there were variations in what is being printed to the console between Firefox and Safari.
By the way, the props were not filled in at created or mounted in my case since they depended on an asynchronous network operation. So, my console debugging looked like this;
created(){
setInterval(() => {
console.log(this.myProp);
}, 5000, this);
}
Long story short, by going up this way, component to component, variable to variable, I found out that I was relying on this date provided by my helper function in a helper file outside of my components and this was why no error was logged to the console at runtime even though multiple components were not being rendered correctly.
I have an issue that I can't seem to figure out. I'm using ractiveJS for a DNS management system I'm building.
I'm trying to add a new record to the end of the existing records. I'm using ractive.get('A') to retrieve the current records. I'm then building a new object
var thisRecord = {};
thisRecord.hostname = "hostname";
thisRecord.ip = "123.123.123.123";
I'm then using records.push(thisRecord); to add it to ractiveJS. In Chrome, Firefox and Safari, this works fine, in IE11, I'm getting the following error coming back.
Just a note. Even though it's in file auth.js, that file is just a compressed file with a few other files within. The affected line seems to be in RactiveJS and this is the line
return n.isRoot?o=[].concat(Object.keys(t.viewmodel.data),Object.keys(t.viewmodel.mappings),Object.keys(t.viewmodel.computations)):(i=t.viewmodel.wrapped[n.str],r=i?i.get():t.viewmodel.get(n),o=r?Object.keys(r):null),o&&o.forEach(function(t){"_ractive"===t&&s(r)||e.push(n.join(t))}),e
Any ideas would be appreciated!
UPDATE
I've found out this issue is only in Ractive 0.7.3, the behaviour works as expected in < 0.7.3 and in Ractive 0.8.5, pushing an object into Ractive as above doesn't update the model at all.
I couldn't find an answer anywhere as no one seems to be having this issue. Upgrading to RactiveJS 0.8.5 seems to have fixed the issue, although had to do a bit more work to make other things work again...
Seems 0.7.3 to 0.8.5 had some breaking changes done, which can found here docs.ractivejs.org/0.8/migrating
Update 2:
After forgetting about this for a week (and being sick), I am still out of my depth here. The only news is that I reran the tests in Safari and Firefox, and now Safari always fails on these tests, and Firefox always times out. I assume I've changed something somewhere, but I have no idea where.
I'm also more and more certain there's a timing issue somewhere. Possibly simply code going async where it shouldn't, but more likely it's something being interrupted.
Update:
I'm less interested in finding the actual bug, and way more interested in why it's intermittent. If I can find out why that is, I can probably find the bug, or at least rewrite the code so it's avoided.
TL;DR:
I'm using Karma (with Webpack and Babel) to run tests in Chrome, and most of them are fine, but for some reason 7 tests get intermittent failures.
Details:
So! To work!
The six first tests MOSTLY succeed when I run it in the debug tab, and MIGHT fail. The failure percentage seems higher when running it normally, though. These six tests are related, as they all fail after running a specific method which functions as a safe delete() for some Backbone models. Basically it's meant to check and clear() all linked models in the model to be deleted, and return false if it's not able to do that.
And had the failures been 100%, I am sure I would find the error and wink it out, but the only thing I know is that it has to do with trying to access or change a model that has already been deleted, which seems like it's a timing thing...? Something being run asynchronously but shouldn't perhaps...? I have no idea how to fix it...
The seventh test is a little easier. It's using Jasmine-Jquery to check if a dom element (which starts out empty) gets another div inside after I change something. It's meant to test if Bootstrap's Alert-system is implemented correctly, but has been simplified heavily in order to try to find out why it fails. This test always fails if I run it as a gulp task, but always succeeds if I open the debug tab and rerun the test manually. So my hypothesis is that Chrome doesn't render the DOM correctly the first time, but fixes it if I rerun it in the debug tab...?
TMI:
When I say I open the debug tab and rerun the test manually, I am still inside the same 'gulp test' task, of course. I also use a 'gulp testonce', but the only change there is that it has singleRun enabled and the HTML reporter enabled. It shows the exact same pattern, though I can't check the debug page there, since the browser exits after the tests.
Output from one of the first 6 tests using the html reporter.
Chrome 47.0.2526 (Mac OS X 10.11.2) model library: sentences: no longer has any elements after deleting the sentence and both elements FAILED
Error: No such element
at Controller._delete (/Users/tom/dev/Designer/test/model.spec.js:1344:16 <- webpack:///src/lib/controller.js:107:12)
at Object.<anonymous> (/Users/tom/dev/Designer/test/model.spec.js:143:32 <- webpack:///test/model.spec.js:89:31)
Output from test 7 using the html reporter.
Website tests ยป Messaging system
Expected ({ 0: HTMLNode, length: 1, context: HTMLNode, selector: '#messagefield' }) not to be empty.
at Object.<anonymous> (/Users/tom/dev/Designer/test/website.spec.js:163:39 <- webpack:///test/website.spec.js:109:37)
Now, the first thing you should know is that I have of course tried other browsers, but Safari has the exact same pattern as Chrome, and Firefox gives me the same errors, but the error messages end up taking 80MB of diskspace in my html reporter and SO MUCH TIME to finish, if it even finishes. Most of the time it just disconnects - which ends up being faster.
So I ended up just using Chrome to try to find this specific bug, which has haunted my dreams now for a week.
Source
Tests:
https://dl.dropboxusercontent.com/u/117580/model.spec.js.html
https://dl.dropboxusercontent.com/u/117580/website.spec.js.html
Test output (Since the errors are intermittent, this is really just an example): https://dl.dropboxusercontent.com/u/117580/output.html
OK, all tests now succeed. I THINK this was the answer:
Some tests called controller, and some tests called window.controller. This included some reset() and remove() commands.
After doing a rewrite, I still had failures, so I did another rewrite. As part of that rewrite, I decided to make all calls through window.*, and after that rewrite all tests succeeded.