Qooxdoo - Theme to use is not available - qooxdoo

I have an qx v2.0.1 app working off the local file system and it runs fine in Firefox v14, but in Chrome v18 it gives me this error:
Uncaught Error: The theme to use is not available: edd.theme.Theme
qx.Class.define.members.initializeMeta.js:108
qx.Class.define.members.mainAbstractGui.js:82
qx.Class.define.members.baseObject.js:141
qx.Class.define.members.mainApplication.js:38
qx.Class.define.statics.readyBaseInit.js:77
qx.Class.define.members.dispatchEventDirect.js:134
wrappedFunctionInterface.js:451
qx.Class.define.members.dispatchEventManager.js:873
qx.Class.define.statics.fireEventRegistration.js:310
qx.Class.define.members.__fireReadyApplication.js:188
qx.Class.define.statics.onScriptLoadedApplication.js:106
qx.$$loader.signalStartupedd.js:159
qx.$$loader.initUrisedd.js:195
I thought I've come across this before and a ./generate.py distclean fixed it, but not this time. Someone else had a similar bug that was fixed:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=1463
Any ideas?

This question is too tricky, and probably involves things like looking at verbose generator output and your job configs, so it is not really suitable for a Q&A site. I suggest you open up a bug for it at the qooxdoo project.

Interestingly enough, after a computer reboot it started working in chrome again. So the chrome clear browser cache/history everything since the beginning of time must not catch everything. So now it's working again...odd.

Related

PSA - gatsby-plugin-image first paint not loading images only in Chrome

I had a really interesting debugging experience last night so I thought I'd share
On gatsby#4.4 + gatsby-plugin-image#2.4 + Netlify (may not matter) I noticed that I was not able to see GatsbyImage components under these specific circumstances:
only on initial load (hitting a nav button rendered the images)
only on desktop and on Chrome
only in prod (Images were loading perfectly in localhost after running gatsby develop )
The issue for me was that when I migrated from v2 to v4 and swapped out gatsby-image to the recommended gatsby-plugin-image, I forgot to add it to gatsby-config. For whatever reason, using {GatsbyImage} from the newer gatsby-plugin-image does not throw any errors even if you don't add it to gatsby-config. Not only that, the dev preview in localhost will show images rendering perfectly.
To make things even more confusing, {StaticImage} appears to NOT work if the plugin is not loaded in config and Gatsby will correctly tell you that something is wrong.
Anyways, my takeaway is.. always check that all plugins are added to config because in certain cases there is no error handling for that. And always check out dev AND prod builds before pushing code!

Karma Istanbul fix to work with new version of Chrome

In my AngularJs application I'm using Jasmine and Karma for my unit tests.
Recently, after a chrome update (now on 72.0.3626.81) my unit tests starting failing locally (with no change to code). I believe the error is a result of my coverage tool Instanbul.
Sometimes the error appears like this:
An error was thrown in afterAll Uncaught ReferenceError: __cov_iuQO6FdumXRPLjSMopb0JQ is not defined thrown
Other times it will appear within a specific unit test (not sure why).
I searched my application and the only file this __cov_ variable could come from is the return of a function within the Instanbul package, generateTrackerVar() within instrumenter.js.
As no code changes were made I assume that the issue is with the new version of Chrome, perhaps the security settings.
My question what permissions would karama-coverage/istanbul require? OR if anyone suspects the issue isn't security based, then what could be causing this error?
Thanks
EDIT:
I have tried to disable web security in my gulpfile like so:
browsers: [ 'Chrome_without_security' ],
customLaunchers: {
Chrome_without_security: {
base: 'Chrome',
flags: ['--disable-web-security']
}
},
But this didn't solve the issue. Is there a way to set the chrome version in this config?
I managed to solve this by figuring out the hashcode after __cov_ was related to a test file that was throwing an error. I don't know why the error didn't just appear as it normally would, that will be another problem to solve.
For now I managed to figure out the file by logging in instrumenter.js within the instanbul package. Then by removing my coverage tool I figured out the source of the issue. Simply removing the coverage tool would give me a different error but not tell me which file so I needed to do both.

Lost UI Shared Context Error - Running protractor tests in headless chrome

I am attempting to run protractor tests locally using chrome but in headless mode, I have seen the docs and added the appropriate options to my config file:
capabilities: {
browserName: 'chrome',
shardTestFiles: true,
chromeOptions: {
args: [ '--headless', '--disable-gpu', '--window-size=800,600' ]
}
}
Upon running, I encounter the following error:
[1009/122000.081:ERROR:gpu_process_transport_factory.cc(1007)] Lost UI shared context.
I tried removing the --disable-gpu flag as I read this may not be needed in future version of Chrome. I currently have latest Chrome installed (69.0.3497.100) and am using windows 7.
What do I need to do in order to get the tests running in headless mode? My intention is to check I can run in headless mode fine locally and then I want to get it running also in Chrome headless mode on a linux Jenkins node, where we are currently using XVFB but its proving to be too flaky with timeouts in tests for example.
Thanks
EDIT
With regards to others marking this as a duplicate - I should have said that my tests fail to run when I attempt to use the headless option, without the chrome options set, Chrome launches as expected and the test run and pass successfully.
My tests fail with no such element found type errors and if I view the screenshots taken on the failures, I just see a white square inside a black background (probably as per the --window-size option I was setting)
As you mentioned you are using Chrome headless mode on a linux Jenkins node you need consider a few factors as follows:
--disable-gpu
When Headless Chrome was first released as GA (General Availability) by Google Team the article Getting Started with Headless Chrome mentioned that :
--disable-gpu \ # Temporarily needed if running on Windows.
A note was added as :
Right now, you'll also want to include the --disable-gpu flag if you're running on Windows.
As per the discussion Headless: make --disable-gpu flag unnecessary it was clear that :
The --disable-gpu flag is no longer necessary on Linux or Mac OSX. It will also become unnecessary on Windows as soon as the bug SwiftShader fails an assert on Windows in headless mode is fixed.
You can find a detailed discussion on What happened under the hood in the discussion ChromeDriver showing Lost UI Shared Context
So as a first step you need to remove the argument: '--disable-gpu'
flaky tests
You seem to be executing your tests with the argument --window-size=800,600 which implies a reduced Viewport.
In order to utilize the maximum possible Viewport you must initialize the Chrome Browser in maximized mode through the argument: 'start-maximized'
angular
From Angular perspective, you can avoid timeouts by using the proper expected_conditions. You can find a detailed discussion about different expected_conditions in WebDriverWait not working as expected
--headless
Finally, I am not sure what exactly you meant as in ...my tests fail to run when I attempt to use the headless option, without the chrome options set.... Perhaps the argument '--headless' can be invoked only through chromeOptions and no other alternative.
I have the same error while running [1010/161441.019:ERROR:gpu_process_transport_factory.cc(1007)] Lost UI shared context.
but my test runs perfect.I have you referred this https://gist.github.com/cvuorinen/543c6f72f8ec917ebfd596802d387aa3
I hope this below may help you
https://cvuorinen.net/2017/05/running-angular-tests-in-headless-chrome/
https://developers.google.com/web/updates/2017/04/headless-chrome

Class 'SqlFormatter' is missing CAKEPHP 3 DebugKit

I've just installed the latest Debugkit from https://github.com/cakephp/debug_kit.
Everything is working. However, when I clicked on the "SQL Log", the CakePHP logo keeps spinning. I tried to debug by opening up the console.log and saw an 500 error. It shows the below.
Error: Class 'SqlFormatter' not found
File /Applications/MAMP/htdocs/App/vendor/cakephp/debug_kit/src/Template/Element/sql_log_panel.ctp
Line: 24
From my understanding, SqlFormatter class is not found in sql_log_panel.ctp. How can I add/declare the SqlFormatter class?
Just install it via composer, problem very likely solved then.
https://getcomposer.org/doc/00-intro.md
http://book.cakephp.org/3.0/en/installation.html#installing-cakephp
I highly recommend you to become familiar with composer, it is a standard tool for php developers for some time now. Composer will automatically install the dependencies for you.
Your second best option would be to download the SqlFormatter package manually from where ever it comes from and set your autoloading or include manually up.

Sencha touch app remains on blue loading screen when viewing on Android device or emulator

I just created a basic sencha app by
sencha generate app --name AndroidDemo --path ../demo
and I viewed it in browser and everything is perfect.
I then followed the instructions here: http://www.sencha.com/blog/android-setup-for-sencha-touch/
and compiled the app with Sencha Cmd and when the emulator opens I only get a blue loading screen.
I also tried compiling/building the app with phonegap on phonegap build site and the build finishes successfully and after loading the app in my andoid device, again I only see the loading page and it stays on this page and the app does not launch.
I'm completely clueless. Need your help friends.
Thanks,
In your app code may be miner syntax error or other error so while app run in emulator check log cat or other option run or app in chrome and check console log. Because loading screen display in case of error as my expression with this.
i'm having the exact same problem..
(currently on windows, btw)
while it's not exactly a solution,
a workaround that i did (out of desperation to see the rest of my app on the emulator):
is to just install it directly to the emulator using the "adb" command.
haven't tried this on a mac, but i'm guessing it's almost the same thing?
after building the app using "sencha" cmd, open cmd/terminal to the build directory.
-assuming you did not change the output location, the apk will be created in your
project root folder under this folder:
"build\native-package-mobile\MYAPPNAME\packager.json\"
make sure the emulator is already running
run the following in command/terminal at the folder where the apk is located:
adb install -r MYAPPNAME.apk
wait for awhile and it should say successfully installed.
run the app in the emulator and hopefully it will go beyond the loading screen.
I don't know why this issue is happening though.
(only started tinkering with android dev/sencha yesterday and it seems to be doing all in it's power to prevent me from running my app. haha)
please share if you find the correct fix for this :)
This usually happens when you build your version and you did not imbed all needed components.
For example, when you use ...
Ext.Image
... in your code.
While running without ...
Sencha app build xxx
... Sencha will grab the component from the touch/src components folder.
But at the time you build the app, it cannot reference to that folder any longer and Sencha will stall.
Please open the console and look out for a warning like this:
[WARN][Anonymous] [Ext.Loader] Synchronously loading 'Ext.MessageBox';
consider adding 'Ext.MessageBox' explicitly as a require of the
corresponding class
You need to add these to the requires section of either App.js or a class where you use the item (here Ext.Messagebox).
Another way to find out what is happening is to run the build code inside the browser and look into the console (so instead of localhost/myapp/index.html you run localhost/myapp/build/{package}/{myapp}/index.html).
There is one other thing that might happen. It’s the scope of async operations.
Like this:
Ext.defer(function() {this.log(‘all good’);}, 500);
this is not the scope of your class.
You need to use:
Ext.defer(function() {this.log(‘all good’);}, 500, this);
Or you might even use ...
Ext.bind()
...to bind the scope to the function.

Resources