I want some personally developed JavaScript code to execute whenever I load a page in Safari. Seems like addblock for Safari does this. Anyone know how to do this?
Safari is not extensible. There's no addon framework for it. But yet there's adblock and verious other addons available for it, although Apple's Webkit and Safari developers discourage users from using them, calling them 'binary hacks'. Seems though some of these addons use InputManager, which isn't documented at all anywhere, at least for not for how people are using it to load scripts in Safari. I guess I'm going to have to backwards engineer to see how addblock does it, but before I do, I thought I'd ask around here. Anyone know?
Input managers are a commonly (ab)used way of injecting arbitrary code into another application's runtime. Once you are there, you have to reverse-engineer enough of the application itself to figure out how to get the behavior you want; usually that involves method swizzling to replace parts of the application you are hacking. It's not documented because there's no API to document, but you can learn about the individual pieces (how to write an input manager in general, how method swizzling in Objective C works, how to use tools like class-dump) and then put it all together.
What you are describing sounds like Greasemonkey though, and there are least one or two hacks already out there to enable Greasemonkey-like behavior in Safari. I'd suggest seeing if one of them meets your needs first.
Related
When I’m programming a Web app and I run into a problem that only seems to happen in one browser, I know that a somewhat-essential step among my overall programming tasks as a “good citizen” is to stop coding for a bit and take time to report the bug in the right place—so it can get fixed and other Web developers (including me) hopefully won’t run into the same problem later.
In such cases with Firefox, I understand enough to know when the cause of the programming problem I’m seeing is in the core “Gecko” browser-engine code in Firefox (rather than instead being, say, a bug in the Firefox user-interface code—the code for the so-called browser “chrome”).
Given that, is there a URL that will take me directly the form where I can quickly get to the right bugzilla “product” and “component” to report a Gecko browser-engine bug against?
Having already reported a few bugs in the Gecko code, I am somewhat annoyed at being forced to use the form at https://bugzilla.mozilla.org/enter_bug.cgi, which seems to assume I’m reporting a bug for the first time and I want guided step-by-step help. But this ain’t my first barbecue…
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=default is the URL you want.
That’s because in the case of Firefox, the right bugzilla “product” to use for browser-engine (Gecko) bugs is actually Core (not the Firefox component—and there is no Gecko component).
That URL above takes you directly to an actual bug-reporting page—that is, as you’d want, it completely skips all the designed-for-first-time-bug-reporters step-by-step guided-help stuff.
You do need to then manually choose the right “component” from the Component list there, but if you already know the right component, you can make a bookmark that includes it; e.g., https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=DOM%3A%20Workers&format=default is a URL that will let you report problems with Firefox Web-Workers behavior.
Adding the &format=__default__ parameter/value is the important part needed to get bugzilla to skip all the designed-for-first-time-bug-reporters step-by-step guided-help stuff.
I'm not sure I get the value of using Modernizr. I read, and reread their site. What is the value in having a script that performs tests to see if a browser has the ability to have the latest html5/css3 features? Does it actually PROVIDE the feature if the browser doesn't natively do it? Seems like a lot of work to do what jQuery can pretty much already do.
It does provide some features through polyfills
"The name “Modernizr” might throw you for a second, we’ll admit. The
library does allow you to use the new HTML5 sectioning elements in IE,
but aside from that, it doesn’t modernize any other features. The name
Modernizr actually stems from the goal of modernizing our development
practices (and ourselves)."
http://modernizr.com/docs/#polyfills
In Firefox there are plugins and extensions. Could you please explain to me why these addons have different name and tabs ? Does they differ so much so they need different names? I think it's a little unnatural to differ these things, extensions have so much and more functionality, what they lack for comparing to plugins?
The difference is both historical and real:
plugins are compiled, loadable modules, originally descended from NPAPI; they can live outside of the browser's process space (which leads to all kinds of fun interoperability issues and vulerabilities). The most common examples of these are Flash and Java - both request a sub-window ("viewport" or "canvas" (not HTML5's canvas - that's something else altogether: a native part of the webpage)) inside the webpage and handle it themselves, in a way that's largely independent of the browser.
extensions are written mostly in JavaScript and XUL. Since the extensions act as part of the browser, they have wider access privileges than JS-in-a-webpage, but they are still subject to some limitations. The most common way of integration is to hook into some part of FF's functionality and extend it.
So, although the plugins and extensions might appear to be related, they're very different technologies behind the scenes.
According to Mozilla, plugins help the browser display content, such as playing media. Extensions actually add new functionality to the browser.
See the first couple paragraphs here:
https://developer.mozilla.org/en/extensions
One are programs which runs side-by-side of firefox. They get a canvas and when they paint on the canvas, firefox renders it. Notable examples: Flash, Java, QuakeLive.
The other are programs which run in the javascript interpreter/compiler of firefox. They extend firefox functionality more directly, since they have access to the firefox internals and are not merely a canvas. Also, they are much more portable since they do not require underlying support of the operating system as much.
There are advantages and disadvantages to both approaches, and they solve different tasks.
My company makes its money off of a great user experience using IE6, 7, Firefox and Safari. 90% of our traffic ends up IE and probably 60% of that traffic is still IE6. IE6 has a bunch of known gotcha's such as accessing DOM objects while they are still being inserted crashing the browser. Almost none of these issues surface during routine testing, they almost always include some odd timing race condition that only affects our most important client of the week.
What process or tools do you use to ensure that known patterns that crash IE are not present in your code?
Added: For those suggesting sticking to 3rd party libraries: I agree that it will help a lot, but you still have to glue those APIs together with Javascript. Is there anyone that is not just crossing their fingers and waiting for someone out in the wild to let them know that there code has just crashed their system?
We don't worry about it. Instead, we use a third party tool like jQuery (well, EXACTLY like jQuery in our company) to ensure cross-platform idiosyncrasies are handled.
I recommend you rely on as many popular 3rd party frameworks as you can. They've undergone far more revisions and testing than you can ever perform. Obviously this means you should be using jQuery for all your JS related work.
Unfortunately there is no silver bullet for these browser bugs, as long as you go with JS & HTML you will continue to have these gotchas. At best you can compile a list of them, publish them on a blog, let the community discuss them and make sure all your devs learn them.
This is an example why Flash and SilverLight exist, which may seem like shocking suggestions considering you've spend an unmeasurable amount of time developing your UI, but if you want to be free of browser/OS bugs, going with a 1 company delivery package is the only way to break the 99.9% barrier for web bugs.
I do a try on window.event.srcElement (which'll only work in IE) and put the non-IE stuff inside the catch, and tie stuff up in my finally.
All other browsers seem to throw an exception with window.event.srcElement so I use that line first and if it gets passed that line it'll obviously be IE so I place my IE code there, if it ever goes to the catch it's clearly a browser that is a bit more standards compliant so I put the alternate code there.
This has saved my ass a lot when it comes to writing Javascript events dynamically using server side code that involves mouse events.
Hope that helped, gives you a way of supporting multiple browsers with different code without server-side detection.
Beleive it or not some of jQuery (and other libraries) functions don't work on all browsers.
Beleive it or not some of jQuery (and
other libraries) functions don't work
on all browsers.
Ofcourse, if you relate to IE5 or NN4, jQuery may not be the best pick. Otherwise, you won't have a problem with this.
I use jQuery for a HUGE site and i don't have problems with library. I have problems with plugins, but this is a different story.
And btw, i have less than 10 lines of pure js in my files. If you learn to use jquery efficiently, you won't need any js knowledge (sounds weird, but... this is my case :P )
We provide a web application with a frontend completely developed in Adobe Flash. When we chose Flash 6 years ago, we did so for its large number of features for user interaction, like dragging stuff, opening and closing menus, tree navigation elements, popup dialogs etc.
Today it's obvious that AJAX/JS offers roughly the same possibilities and because of the number of frameworks that are readily available, it's very feasible to implement them.
Is there a technical reason one should choose either technology over the other? By "technical", I mean performance, security, portability/compatibility and the like. I don't mean aspects such as the very non-programmer way development is done in Flash or whether it makes sense to switch an app from one to the other.
As I just explained in another question, it seems to me that JS is way ahead in terms of market share and I'm wondering whether we are missing some important point if we stick to Flash.
In addition to what others have said, Flash is constrained in the "rectangle" and cannot be added to a normal html page in an un-obtrusive manner.
#Gulzar I think when more browsers will support the video tag like mozilla 3.1 does we'll see even more adoption of ajax/js over flash.
Adobe Actionscript is a statically typed language, Javascript is dynamically typed. Depending on your point of view, this may be a good thing or a bad thing.
With Javascript/HTML/CSS you're going to be heading into cross-browser compatibility hell, especially if you want to support older browsers. This can be mitigated by the libraries that are available, but it's still a big headache. With Flash, you write the code once and it just works in all browsers.
Even with the libraries available, Flash user controls are simply more advanced than anything you can find in the world of Javascript/HTML. In Javascript, you are not going to find anything that comes close to the simplicity and power of a databound user control that Flash provides.
I don't see how Javascript has more of a "market share" than Flash. Pretty much anyone with a web browser has a Flash plugin installed. I'd be curious to know how many people disable Javascript but have a Flash plugin.
Also keep in mind that you're going to be in for a huge learning curve and lots of development time if you decide to switch your technology base so you'd really better have a good business reason to do it.
This decision also has a lot to do with what your application does and who your install base is.
Edit: I see people have mentioned that the iPhone doesn't have Flash support. I would expect this to change with the install base of the iPhone - Adobe would be crazy not to support it.
Correctly designed AJAX apps are more googleable than Flash
Correctly designed AJAX apps are more easily deep linkable than Flash
AJAX doesn't require a plugin (Flash is pretty ubiquitous, so it's not really a big deal)*
AJAX isn't controlled by a single company the way Flash is
Edited to add:
* Except for the iPhone, as Abdu points out.
JS and Flash both have great presence on the web with overlapping capabilities. One area JS is still lacking is in rendering video.
Flash, used well, allows easy localization and internationalization.
Furthermore, it is much easier to use Flash in an accessible manner; you can feed screen readers the right text, instead of having them iterate over all of the possible form elements.
I think Flash should be limited to online games, videos and animation. Otherwise use html and Ajax. It's a web standard and supported by almost all devices.
AFAIK, the iPhone doesn't support Flash. That's a fast growing segment you're blocking out already. Keep it simple and efficient.
Although flash is pretty ubiquitous on desktop browsers, mobile support is very limited (flash lite? yeah, right). I get really frustrated looking up a restaurant on my phone only to find the entire site is flash based and I can't even get a phone number or address!
One benefit of Flash is that it has a few facilities to help do cross domain type operations safely, which can be helpful. Flash also has (limited) support for some hardware, which is not possible with Javascript.
Personally, I'd try to use as much Ajax as possible before turning to something like Flash. From the UI perspective, it is better in that the controls and basic authoring is a little more developed. The Sound Manager project is a good example of effectively using a small amount of Flash while keeping the remainder in Javascript.
I suspect one of the reasons javascript is becoming more popular is that it's more easy to retrofit into an existing application.
As I can't accept two answers, I'm going to merge Christ Upchurch's and 17 of 26's answers in my own post. I think, these two together pretty much sum up what I wanted to know. Thanks guys!
If you're dealing a lot with polygons, then Flash is still easier to program and debug. With AJAX there are a lot of libraries to handle polygons, but the more libraries your app uses, the slower it gets.