My webapp uses YUI library exactly as recommended in the doc:
<script src="http://yui.yahooapis.com/3.18.1/build/yui/yui-min.js"></script>
PROBLEM: Modern browsers do not load it anymore, citing mixed HTTPS/HTTP concerns.
Replacing http with https in the URL above does not work (they have a certificate problem).
Copying yui-min.js to my HTTPS domain does not work either, because the JavaScript seems to contain its own URL within its minified source code, for instance here:
[...] var p,b,q="3.4.1",h=".",n="http://yui.yahooapis.com/",t= [...]
I tried modifying the variable above directly in the minified code, but that broke things as now YUI for some reason tries to load https://myserver/combo, which obviously does not exist.
QUESTION: What is the right way to switch the YUI library to HTTPS?
http://blog.andrewbruce.net/why-is-serving-yui3-over-https-so-hard describes this problem as "one of the most frustrating development problems I’ve come across in my career", and describe how 3 techniques failed, and how he resorted to perform network sniffing and identify traffic for each browser he wanted to support. I would like to avoid this as I can not test on all browsers.
A recent glimmer of hope is the appearance of https://yui-s.yahooapis.com/combo?2.6.0/build/animation/animation-min.js which might lead to a usable HTTPS/YUI without having to go through much trouble.
Similar old question, but sole answer is based on YUI Configurator, which has been deprecated and is now unavailable.
Related
I'm developing an extension and I'm a bit stuck about the communication between the web-app, the content-script of the extension, and the communication between the content-script and the background-script. It seems to be that HTML5 Messaging API is to be used, but how to do that in a precise context is not only hard to understand and implement, but also confusing due to differences of approach in Browsers (which seemingly support the same API).
For example, Firefox doesn't recognise the externally_connectable in manifest.json, which is where one assigns permissions for the hosts where requests originate from. So how does Firefox expect you the developer to assign the permissions? I assume it expects you do that within the content-script?
Particularly, I'm confused about what is the best way to exchange data between the app and the content/background script. Is the best way postMessage / addListener methods and do they work in all contexts; or as someone mentioned: window.dispatchEvent should be preferred?
All guides relevant to the point above are appreciated.
Messages coming from outside the extension is not something I have experience with (and I'm not sure that's what you mean).
You should make sure you thoroughly understand the chrome extensions overview which is definitely required reading.
re Window.dispatch and using other APIs, my suggestion is stick to the chrome.xxx APIs unless there's something they can't do.
There are 3 scopes potentially in your extension that can only communicate by messaging but the messaging is simple to implement and actually can lead to good designs.
Content scripts are the key to interacting with the page itself but their scope isn't the same as the page, the js is isolated but they can access the DOM of course.
Content scripts can be loaded when every page loads or just some pages by including them in the manifest. Or powerfully, they can be injected by the background page or the popup - so if you're intention is to control from the popup, you can use programmatic injection - a useful pattern is that the popup (or background) can launch a url in a tab, inject jquery (any version because it's isolated), then inject the content script, the content script can then use $(document).ready() to wait for the page to be loaded (don't have to use jQuery but the fact that you can without caring whether the page has jQuery or not, or what version it might have) is useful.
If you already knew this much, you might not be as confused as you think :)
I'm currently developing a Chrome extension and planning to publish it on Chrome market. I'm aware of open-source community benefits, however, do not want to share the source code and a bit worried about copyrights. Currently, the plan is to minify and obfuscate the source code before publishing. So the questions is:
Does Chrome Market accept extensions with minified and/or obfuscated source code?
Thanks in advance! :)
Any existing answers above have been rendered obsolete by the terms change on January 1st, 2019. This change was announced on October 1st, 2018.
In summary:
Google Allows minified code.
Google disallows obfuscated code.
The specific policy, available at https://developer.chrome.com/webstore/program_policies, is as follows:
Developers must not obfuscate code or conceal functionality of their
extension. This also applies to any external code or resource fetched
by the extension package. Minification is allowed, including the
following forms:
Removal of whitespace, newlines, code comments, and block delimiters
Shortening of variable and function names
Collapsing files together
2019 Update:
Google allows minified code, but not obfuscated one. See Brian's answer
Original answer:
Yes, you can use obfuscation tools (like jscrambler) before publishing your extension. I don't know if that may delay the publishing time, but I know for sure that are some published Chrome extensions with obfuscated/minified source code.
I, for instance, minify the code of my extension (LBTimer) with Google's Closure before publishing it.
It looks like they don't approve minified and obfuscated code. You can check thread on the Chromium Google Group, from April '16.
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/1Jsoo9BPWuM
No, you cann't. This is email I received from Google Chrome Team: All
of the files and code are included in the item’s package.
All code inside the package is human readable (no obfuscated or minified code).
Avoid requesting or executing remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests).
You can get a more specific answer if you contact the Google Chrome team.
Update with own experience:
I wasn't able to submit a build obfuscated with this javascript-obfuscator (more specifically, gulp version in my case) They were complaining about "your code is suspicious" so I guess something triggered an alert in their system.
However uglyfy worked for that - I still had to figure out a way to rename all the prototype functions as uglify doesn't seem to do that (or at least I wasn't able to find a way to do that)
Original answer:
To sum up, it seems like chrome extensions are allowed to be minified and obfuscated.
For more details, keep reading.
First of all, there are two different terms - chrome extension and chrome app and different rules applies based on that. Chrome app has more strict requirements and it seems like mcastilloy2k's answer is suitable for chrome app (at least it looks like it is based on the available policies for both).
And regarding the below google's answer:
Avoid requesting or executing remotely hosted code (including by
referencing remote javascript files or executing code obtained by XHR
requests).
If it's for chrome extension and not for chrome app that seems strange as per the extension FAQ from google which explicitly states that extension is allowed to make external requests to execute custom API aka 'remotely hosted code':
Capabilities
Can extensions make cross-domain Ajax requests?
Yes. Extensions can make cross-domain requests. See this page for more
information.
Can extensions use 3rd party web services?
Yes. Extensions are capable of making cross-domain Ajax requests, so
they can call remote APIs directly. APIs that provide data in JSON
format are particularly easy to use.
Can extensions use OAuth?
Yes, there are extensions that use OAuth to access remote data APIs.
Most developers find it convenient to use a JavaScript OAuth library
in order to simplify the process of signing OAuth requests.
Another discussion in this google groups thread shows that rejection might not be connected with obfuscation at all:
Eventually, these are the things I needed to do to get my extension
passed (but I keep my fingers crossed in case some other validation
test still has to be performed):
I created a privacy policy and added a link to it on the Google Chrome developer dashboard.
I explained in more detail what my extension is doing. It seems that Google needs this to have a better understanding of the extension.
In the description I explicitly stated how the extension handles personal or sensitive user data.
Eventually that was enough to get the extension
pass the checks even with minified & obfuscated code (but remember I
keep my fingers crossed).
Moreover one can always go and check existing extensions out there, like Grammarly for example, who has obfuscated code (to some extent at least) and who uses external API.
I've found this nice article about the "injected Way", but the author never finished it :
http://hightechstartups.blogspot.ch/2012/05/different-way-of-developing-browser.html
I would like a bare bone cross browser extension, without any 3rd party extensions or framework (to be as light as possible and not dependant on a 3rd party) that would load Jquery and a JS from a distant server and the ability to load it before or after the page is fully loaded.
I've read a lot of topics about the subject, but since IE10, Chrome 26 and FF20 are out with their new cross-link limitations, i was wondering if somebody had ressources, source code or tutorial about the following requirements :
I need :
Cross browser extension supporting (IE 8+ or 9+ worse case, Chrome
26+, FF20+, Safari)
Ability to inject a single JS hosted on another server. Inserts a script tag that references a javascript file in the head of the HTML
page and then be executed
Not be dependant on a third party extension (greasmonkey) or framework (Kango, Crossrider)
Ability to load before or after the page is fully loaded
This method allows me to customise the browser extension depending on the user's location and it also avoid having updates as the JS is updated on each page refresh.
I'm aware of the downsides, but i would like to achieve this.
I'm aware of cross browser framework like Kango or crossrider, but both don't fit me needs.
The closest example i could find is this How can I run a <script> tag that I just inserted dynamically from a BHO
but it only covers IE and as i got very little Csharp experience, i would like to see a full example to understand it properly and learn from example.
I would LOVE to have a few examples, even if it's not cross-browser (IE being the worst part for me).
Thanks a lot for your support !
Update1:
About Kango and Crossrider, Kango is 2000$ if you want to use IE and for Crossrider you're required to be distributed and monetized by them.
I've managed to code for IE and Chrome, but i was looking for an "elegant" way and figured it was the best place to ask given the level of knowledge of people on this site.
For the installer i currently use NSIS, but i'll test Wix too.
Finally i guess the only way for me would be to learn C++ and .net to get it to work with IE, but if anyone could provide more source code it would be great to test speed and compatibility and discuss here what's the best solution.
Why do Kango or Crossrider not fit your needs? Both frameworks allow you to manipulate the page's DOM (which is what you want):
Kango: Adding content script
Crossrider: documentation, example code
If you want to code your own solution, take a look at the relevant documentation:
Content scripts (Chrome)
The Page mod Jetpack API (Firefox)
Injected scrips (Safari)
Injected scripts (Opera)
Internet Explorer does not natively support extensions. It took me about 80 hours to create a stable and reliable IE extension which supports cross-site AJAX, a (preference) storage method and injection of scripts as early as possible in any frames based on its URL. I developed and tested the extension with Visual Express 2010 on Windows XP and Windows 7, for IE 8-10 (the extension might work on IE6/7, but I decided to not support these ancient and rarely used browsers).
First, I wrote an extension in C# based on LiveReloadIEExtension (a sample IE extension, which in turn is based on this Stack Overflow answer - see also this blog post). It was functional, but it required .NET 4, lacked support of frames, and it's relatively slow.
So, I decided to write an IE extension from scratch in C++. A good starting point is available at http://www.wischik.com/lu/programmer/bho.html: Sample code for C++ BHO, which changes the document's background based on key/mouse events. I've also learned a lot by looking at other code samples on CodeProject, topics on the MSDN forums, questions and answers on Stack Overflow, lots of other blogs, and the MSDN documentation:
DWebBrowserEvents2 interface lists several events which you use to find an appropriate injection point.
Scripting Object Interfaces (MSHTML) lists even more interfaces. You'll be mainly interested in the iHTMLDocument, iHTMLDocument2, ... interfaces.
After creating the IE extension, you want to deploy it of course. I used Wix toolset to create a MSI.
Very random and annoying problem with IE6. We keep our common JS files on a resources server so we only have to update them in one place. As well as our custom classes we also keep our build of mootools and more on the resources server and link to it in the head of our sites.
This is fine in all the browsers accept IE6. In IE6 it seems to not loads the core quick enough from the external link before trying to process the mootools code in my site.js file. It will go wrong on the first line "windows.addEvent".
If i put a mootools core in a folder where the site is though its fine. Does anyone know why it might be doing this and if so a way around it, but still keeping the files on the resources domain?
Thanks
Tom
#neil . Yeah exactly. Quite frankly i didn't want to be rude but the first two responses were a waste of their time and mine. Someone correcting a typo and someone else saying not to bother supporting a browser that still has 9% share of the market, quite brilliant.
#Dimitar Thanks for your response. I can't change the event to load unless you mean in native JS because no mootools will work. I don't like mixing the native JS when i'm using a framework if i can help it. Never heard of "defer" though, i will def try that. Thanks for your help.
IE6 probably pipelines the download as an extra host gives it the ability to do it in parallel.
perhaps you can either try adding defer='defer' for IE6 for your chunk of code that relies on mootools or change the event from domready to load instead (also for IE) (I tend to use the latter)
I want to display a message to users with unsupported browsers, as opposed to having the site fail in an ugly manner.
What's the best way to do that?
GWT also provides browser detection using the .gwt.xml file. Have a look at this:
http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/DevGuideDeferredBindingReplacement
It's an interesting solution, but I'm not sure if it's the best solution in your case. It could be very useful for creating a simplified version of your application which would automatically be loaded in unsupported browsers.
The GWT team does not provide a list of unsupported browsers, only supported browsers, and it's a vague list at that "most recent versions of Internet Explorer, Firefox, and Safari. (Opera, too, most of the time.)".
If you have a good idea yourself of what browser/version won't work you can use this code:
public static native String getUserAgent() /*-{
return navigator.userAgent.toLowerCase();
}-*/
to learn what browser is being used and perhaps cook up a work-around.
On the other hand, browser rendering of web pages can fail in many subtle ways ranging from mildly annoying to catastrophic, and there is often no way to know where your page falls on that scale. One of the major reasons for GWT is that you can stop worrying about this sort of thing. At least until it happens.
If you want to make it simple and stupid, check with some javascript code in your main html file, before GWT is loaded. Novertheless, I would rather trust GWT to handle things more or less quirky. You could also just recommend chrome or firefox.
I realise this is an old question, but I had the same problem, and wanted to share a new solution for it.
Today with GWT2.7 "obsolete" browsers try to download undefined.cache.js. This obviously fails and the client is stuck forever.
You could patch GWT itself setting fallback compile steps, but the easy solution is to simply provide a (manually crafted) undefined.cache.js and place it where the other generated files are.
Inside you put this one line:
xxxxxxx.onScriptDownloaded(alert('This browser is not supported anymore.\nPlease upgrade to a more recent browser.'));
where xxxxxxx is your module basename (from xxxxxxxx.gwt.xml).