I have spent hours with this issue. I'm about ready to tear my project apart, line by line to get this figured out. But I was wondering if anyone else had this issue:
My project works great in Firefox. My customers use IE (classic - alot of people do...). My boss wants me to get this done yesterday.
I can't get IE 8 or 9 (with my document in IE 7 emulation mode) to run the following, and load the TabView. I get an error in the debugger console that telling me that it doesn't load it. I have all the required modules for tabview loaded via tags, so there is no dependence on an Internet connection - offline operation (again.. works great in Firefox).
YUI({bootstrap:false,insertBefore: 'yui3-style-overrides', filter: ''}).use('tabview','tabview-base','event-synthetic','event','event-custom','event-mouseenter','oop','yui','dom','dom-base','node','io','datasource','resize','anim','anim-easing','event-base-ie','dom-style-ie','node-focusmanager','node-event-simulate','plugin','classnamemanager','pluginhost','event-base','tabview-plugin','attribute','base','widget','widget-base-ie','arraylist','widget-parent','widget-child','event-simulate',function(Y) {
/* sand boxed code here */
});
Recently yui (3.2 or 3.3) factored out their ie fixes into separate files in the build. This caused a nightmare for me as well. You could test it with 3.1.1 if you want to isolate your variables.
What contributed more to my insanity was that I was stupid enough to use the YUI PHP Loader, which gets worse with every YUI release because YUI is getting so many dependencies even hacked up crap like the PHP Loader cannot account for all situations.
I worked around this by manually loading all the -ie- files using
<!--[if IE 7]><script type="text/javascript" src=myfile.js></script><![endif]-->
for a month or two before I was able to come up with a smarter but larger version of PHP Loader (Which, alas, I cannot share).
To see if this is your problem, use that if ie script above for every IE specific file in the build folder. Here is a list:
build/dom/dom-style-ie-debug.js
build/event/event-base-ie-debug.js
build/history/history-hash-ie-debug.js
build/scrollview/scrollview-base-ie-debug.js
build/widget/widget-base-ie-debug.js
If I were you, I'd manually load all of those except for maybe history, which you might not need - just so you can minimize your variables.
TBH, when I had this problem and troubleshot it, I loaded every yui JS file. It took a while, but the bug disappeared and I was hot on the trail of finding the -ie- files issue.
Related
I have a site that is using fontawesome. I am lazy loading many of the CSS files to increase first page load time, etc.
However, I need the fa-phone-alt to working on first load because it appears at the top of the page.
Can anyone provide guidance as to how I an add inline style just for the fa-phone-alt so that it works without having to load the entire style sheet?
Hope I am explaining this well enough.
Thanks.
I'm not sure how to solve exactly what you're asking, but a workaround could be that you download an SVG of a phone and place it so it loads instantly.
I am trying to port over a bit of code from wx2.8 to wxPheonix (3.0.3.dev78356 msw). I'm using code from the pyfa project (https://github.com/DarkFenX/Pyfa) which is currently being rewritten for python3. This code takes some concepts from PyCollapsiblePane and implements it better (there are some bugs with PCP). If you download and open pyfa, the collapsible panels are on the right side (resources, resistances, etc) if you want to get a feel for how it is supposed to work.
Anyway, I'm trying to port this over and I cannot seem to get it to work well. I know Pheonix introduces some changes to sizers and how things are resized. I am able to collapse the panel (and have the parent panel fit to the new size), and then open it again. But when I try to collapse it again nothing seems to happen.
Here's what is currently happening:
http://gyazo.com/68717f66c498d850ef60ee83e1c0ae4a
And here is how it's suppposed to work (wxPython 2.8 in the pyfa app)
http://gyazo.com/87cc0f61052dca0e81c387da0f84c0c4
This is the module that I'm working on (the script has a test case if run directly): http://pastebin.com/ghuVGXWN
Any ideas?
I had to remove self.SetMinSize(sz) from OnStateChange, works great now.
In manifest.json, we specify our background page and can put an html or a js file for it. Since it is only a script that executes what sense does it make to have an html file for it?
I mean where is UI going to get shown anyway?
Similarly the devtools_page property has to be an html file. What sense does that make?
It will not be shown anywhere (that's the essence of "background"), but some elements on it make sense.
You can have an <audio> tag, and if you play it, it will be heard.
You can have an <iframe> with some other page loaded invisibly.
..and so on
As for devtools_page, it would actually be visible in the interface (as an extra panel in the DevTools)
It is possible that devtools_page must be an HTML file just for legacy reasons: it was not updated when manifest version 2 rolled out with changes to how background pages are specified. Still, the same arguments as above apply.
background_page is a legacy feature from the initial support of extensions in Chrome. background.scripts was added in Chrome 18. I can't speak for Google's original intentions but I'd guess that in the original design using an page felt more natural and would be less likely to confuse developers. Once they realized how many background_pages were just being used to load JavaScript it made sense to explicitly support that.
I'm using Bootstrap files within my application and I want to enable "Use runtime optimized JavaScript and CSS resources".
the problem I have is once enabled; glyphicons-halflings-regular.eot, glyphicons-halflings-regular.svg and glyphicons-halflings-regular.woff cannot be found:
I know for Bootstrap 2.3 we could use a Theme that loads a .CSS file that changes relative locations as described here http://www.bootstrap4xpages.com/bs4xp/site.nsf/article.xsp?documentId=F435B6DC54486B67C1257B6B002E5A6C&action=openDocument
So, what should I do to handle relative locations with Bootstrap 3?
You have to tweak the path to the web font resoureces in the Bootstrap CSS files.
Delete the part with "../" and replace it with the relative path to the font files within your project structure, e.g.
bootstrap/fonts/...
Then aggregation will load the fonts correctly.
This does not answer your question but if you want to use Bootstrap 3 you'd be MUCH better off using the Boostrap4Xpages project on OpenNTF.org. It will perform better and the resource aggregation will work better. It's easy to install and use but it is a plugin on the sever so that needs to be done. It's not self contained to the NSF. Try and move to this if at all possible.
Regarding the actual question. I'm not sure I know the answer specifically. I do know that using relative links can sometimes be a problem if the browser's URL doesn't have the page.xsp portion. So it works on the page.xsp and NOT the default launch XPage where the URL ends with the database.nsf. What I've done in the past there is set the application to launch to something like "start.xsp" and in that page in beforePageLoad to a redirect to "home.xsp". This forces the browser url to always show the page name and made life a little easier when dealing with adding projects to WebContent.
I have been working on this site for some time and just launched it for a client.
People have actually had trouble beleiving I had done it on WordPress, though I don't see why...
Anyway, I suddenly see that the form fields of one of the forms on the site (Newsletter Registration) disappear while on IE, you get to see them for a second and puff, they're gone. I did check this previously on IE and it worked, I especially used CSS3 PIE to get the rounded effect for the fields on IE...
Link to website: http://www.doritsivan.com (hope this isn't considered promotion, not my intention)
site is based on WordPress and jQuery.
resolved the issue, thank you all. it was a bad case of relative vs. absolute positioning and the fields decided to go away (literaly)
A bunch of debugging with firebug-lite (btw was real to get it to work on my IE, kept on crashing or refusing to load altogether combined with IE popup and security issues) and I understoid that this was the issue, then some pixel fiddling and all was good. rechecked in Chrome, saw that result was exactly the same. job done