PDA

View Full Version : So many examples failed in Chrome!!!



andy13c72back
28 Dec 2011, 5:42 PM
I opened form examples in Chrome and they showed nothing or broken UI. The console outputted 'dom is null' or sth like that.

edspencer
28 Dec 2011, 8:44 PM
Which release are you referring to?

dsk1962
29 Dec 2011, 5:05 AM
ext-4.1.0-beta-1.zip. 'Forms' examples do not work.

Dynamic Forms :


In FF : Ext.util.CSS.getRule("." + Ext.baseCSSPrefix + "form-trigger") is undefined

In Chrome : Uncaught TypeError: Cannot read property 'style' of undefined

andy13c72back
29 Dec 2011, 5:33 AM
Which release are you referring to?

I used 4.1 beta. And today, I switched my project from 4.0.7 to 4.1, almost all forms layouts are broken and behaves weird, so I had to switch it back. I guess there'll be a LONG LONG way for the final release of 4.1.

skirtle
29 Dec 2011, 9:39 AM
There's another thread relating to Ext.util.CSS.getRule returning undefined:

http://www.sencha.com/forum/showthread.php?164988

I'm not saying it's necessarily the same problem, just joining some dots.

silvereen
29 Dec 2011, 6:52 PM
I have opened a similar thread a few days ago showing the errors causing the UI to fail to render under chrome.


http://www.sencha.com/forum/showthread.php?167675

basememara
2 Jan 2012, 2:05 PM
I can confirm there is indeed a problem in 4.1 Beta. My application resides on a cross-domain server. In my Ext.application section, I have the appFolder property pointed to its full URL (so remote sites know where to access it). Where my app resides, I also have enabled "cross-origin resource sharing" via this in Apache:


Header set Access-Control-Allow-Origin *

When remote sites reference my app, I get these errors in 4.1 Beta as others:

In FF : Ext.util.CSS.getRule("." + Ext.baseCSSPrefix + "form-trigger") is undefined
In Chrome : Uncaught TypeError: Cannot read property 'style' of undefined

When I switch my app to use 4.0.7-gpl, IT ALL WORKS PERFECT on the remote sites!

I get dozens of errors in Firebug with 4.1 beta. It looks like they all stem out from here in Chrome:
"Ext.apply.injectScriptElement.onLoadFn ext-all-debug-w-comments.js:8804"



/**
* Inject a script element to document's head, call onLoad and onError accordingly
* @private
*/
injectScriptElement: function(url, onLoad, onError, scope) {
var script = document.createElement('script'),
me = this,
onLoadFn = function() {
me.cleanupScriptElement(script);
onLoad.call(scope); <<----ERROR HAPPENS HERE (LINE 8804)
},
onErrorFn = function() {
me.cleanupScriptElement(script);
onError.call(scope);
};


script.type = 'text/javascript';
script.src = url;
script.onload = onLoadFn;
script.onerror = onErrorFn;
script.onreadystatechange = function() {
if (this.readyState === 'loaded' || this.readyState === 'complete') {
onLoadFn();
}
};


this.documentHead.appendChild(script);


return script;
},

sumit.madan
10 Jan 2012, 2:06 PM
All my applications are broken in 4.1 beta. Even the most basic components which touched tooltips, layouts or forms don't work anymore. If this is the preview of the things to come, I'm afraid the effort to upgrade to 4.1 from 4.0.7 will be as involved as what I faced from 3.4 to 4.0.7

Now, I'm at crossroads again, to decide the framework to use for new projects. Probably I should wait for a 4.1 stable version to be released. However, it looks like a long time before all the issues with 4.1 beta will be addressed :(

brentdooley999
12 Jan 2012, 8:09 AM
I've recently converted our large application from 3.4 to 4.0.7. It took a very long time and a LOT of work. However, I feel like it was a positive experience because upon going through EVERY line of code I found quite a few things that I was able to optimize and make better. The net effect of the conversion was a 4.0.7 application that actually ran better and faster than my 3.4 application.

When the 4.1 performance preview came out a few months ago I tried it and it failed. Nothing would load. I was still converting my code to 4.0.x so I really didn't bother trying to make it work because I knew it was just a preview.

When the 4.1 beta dropped last week it took about 5 mintues to get the thing to work on my local dev environment. I can't get it to work on our test server due to a CSS problem that it currently being discussed, but it works great locally.

Basically, what I'm trying to say is that the 4.0.7 to 4.1 upgrade shouldn't cause any problems if you've coded your 4.0.7 application with the 4.x standards. I'm excited to see 4.1 drop so I can finally merge all of my code into one live version and move all of our customers off of our old HTML application once and for all.

skirtle
12 Jan 2012, 8:33 AM
@brentdooley999. An interesting story and one that resonates with my own experiences. I tried upgrading a handful of my own applications from 4.0.6 to 4.1-beta-1 and while I found a number of nasty bugs I did manage to get everything basically working pretty quickly. Perhaps I was just lucky, maybe I'm not using the features with the worst bugs.

I like to think that I follow best practices and write some pretty tidy code, yet about half of the problems I hit were due to mistakes in my code that had somehow worked in 4.0. All were quickly solved once I realized it was my mistake.

I haven't heard anyone else report speed improvements moving from 3.4 to 4.0.7 but your story is consistent with my own belief that many applications have plenty to gain in performance just by following best practices.

flanders
12 Jan 2012, 9:02 AM
We're also building a new version of our application against 4.1.0-b1 and so far it's going quiete awesome. Not always taken the time to discover beautifull solutions, but this what i can remember from the last week and a half:

Over 5000 lines of JS ported, quite some CSS theming with the only issues faced:

Horizontal scollbars in every grid/tree (already reported)
Models for trees seem to ignore an property 'name' (quickly moved to 'text' since know issues with the models in trees and gave it no further thought so no idea if it is a bug or not
Stores seem to autoload even if configured not to. Adding autoLoad: true keeps the mask in view always. Fixed by removing all autoloads. Don't know if this is reported yet.
In some cases hbox doesn't behave exactly as before. So far solved by just moving to column.
If more comes up I'll update the post

slemmon
12 Jan 2012, 9:17 AM
I had the issue with horizontal scrollbars in my tree no matter what and I reported it and evant wasn't able to reproduce the issue.

If I put the example case on my work Windows servers I get scrollbars. If I put it up on my own personal webserver on linux I don't get the issue - same code.

If you have a test case or any additional details to share you might post it to:
http://www.sencha.com/forum/showthread.php?170603-4.1-B1-Tree-horizontal-scroll-(node-wider-than-owning-container)

T (http://www.sencha.com/forum/showthread.php?170603-4.1-B1-Tree-horizontal-scroll-(node-wider-than-owning-container))hus far it's not formally listed as a bug to my knowledge.

sumit.madan
12 Jan 2012, 11:46 AM
Although everyone have their own definition of standards, all components written in our applications use ext-dev.js and every error is fixed. Though we don't care about MVC, we strictly follow the Ext.define syntax to create new classes derived from base ExtJS components.

That said, the upgrade is ExtJS 4.1beta is nothing less than a complete overhaul of some of our components. The <table> tags to render form fields (and possibly other components) is a surprising choice which is a step backwards from using <div> in the earlier versions to render components. As a result, simple things like adding a padding to fields, using css absolute positioning no longer work.

Tooltips behave erratically, and they turn modal windows into non-modal and steal focus from fields when they are shown and sometimes they don't get shown at all. I read that tooltips are getting a complete overhaul in 4.1 beta 2.

These and other bugs are just off our login page, I'm sure when I start to look into the broken stuff in the main interface (grids, tree, menus, stores etc.) I'll unearth several other issues. The point is, I don't get paid to report bugs for Sencha and with the beta 1 results, I'm worried that the upgrade from 4.0.7 is anything but easy.

The road from 4.0 to 4.0.7 was a long one, and its looking the same for 4.1.

al@Door7
8 Mar 2012, 10:56 AM
Hello,

I loaded up Sencha for the first time to evaluate using for a new project I need to get rolling quickly. This has really stumped, here's what happened.

Files were copied into local web server directory, I went to the examples page, icons had failed to load, clicking on example, doesn't work, get this message -

'The requested URL /sencha-touch-2.0.0-commercial/examples/production/forms_toolbar/index.html was not found on this server.' I tried adding in a 'production' folder to the directory, didn't help.

I looked at javascript console, errors galore. Click around some more, then the example icons load up, test a few, and they look gorgeous. Go home, next morning, same errors pop up, but I can't get it to work on the original machine, and on a second machine.

I'm using Chrome with a local WAMP server, running the files from the server. I figure it must something basic, but can't find it. Any ideas?

Thanks.

mankz
8 Mar 2012, 1:27 PM
Sounds like your includes are messed up? Check net tab for any 404s and make sure to bust the cache too.

al@Door7
8 Mar 2012, 2:18 PM
Sounds like your includes are messed up? Check net tab for any 404s and make sure to bust the cache too.

Sorry, not following about the includes. I haven't written any code, its the examples included in Touch2 SDK that aren't working. I didn't see anything about having to config the sdk...? I just copied it into my server directory. Clearing the cache hasn't work. Thanks for the reply.

pilipenok
20 Nov 2013, 4:10 AM
ext-4.2.1-gpl
Ubuntu 12.04 LTS
Chrome 30.0.1599.114

Failed on autoloading controller class in
Ext.apply.injectScriptElement ext-all-debug.js:6262
6261: script.src = url;
6262: (Loader.documentHead || document.getElementsByTagName('head')[0]).appendChild(script);

The file successfully is opened in separate tab. There're no syntax errors.
There's the same error when the file is empty!

BTW, in Firefox the application works fine.