I am porting over a Chrome plugin to Firefox as a Webextension. I have gotten almost all the way through my rather large codebase and switched things that were incompatible, however a management.onInstalled and .onUninstalled, onEnabled and onDisabled are the last few functions I can't seem to find a Firefox equivalent for. Any suggestions?
These events are not currently implemented in Firefox. If you have a compelling use case for them you can add a comment at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1282984
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 can't seem to find anything on google about this. I know you can pretty much rule out IE. I know webkit supports it but what else do you know?
Ok, this question has been here quite a while, but I wanted to add this anyway.
Regarding a question about browser support, a good source is always the caniuse.com website.
In this case, you can find the current, past and expected future support for the range input here:
http://caniuse.com/#feat=input-range
At the time of writing, apparently (Desktop) Safari, Chrome and Opera support range inputs, according to Dive Into HTML5.
I'm unclear on the difference between the functioning of a plugin vs
an extension.
For years, I've written a plain old NPAPI plugin. It lived in /Library/
Plug-ins on mac and somewhere similar on a PC. With Firefox 3.6, it
stopped working. Looking around, I see this:
http://blog.mozilla.com/security/2009/11/16/component-directory-lockd...
which I figure might be the problem, so I try to turn my plugin into
an XPI, but this turns it into an extension.
I install it, and it STILL doesn't work, but now I don't know if it
doesn't work because extensions are a different beast than plugins,
and so what I did makes no sense at all, or whether it's because of
whatever the underlaying problem was before is still around, and so
what I did was a waste of time, and didn't actually address the
problem...
Can anyone give me some guidance here?
thanks.
The answer is "it's because of whatever the underlaying problem was before is still around". The lockdown post clearly states that you'll have problems only if you put your files inside Firefox.app/.../components (if you mentioned this link in your original post, you wouldn't have to try and make it into XPI).
The relationship between extensions and plugins is: an extension may include plugin(s), among other things. You can install plugins (without making them into an extension) in Firefox.
As for your original problem, unfortunately I have no idea why it doesn't work. I'm not well-versed with debugging NPAPI plugins and the only bit of information you shared is that it doesn't work in Firefox 3.6 :)
As a first step, does it appear in about:plugins or in Tools -> Addons?
You can install a plugin as part of an extension (optionally using an XPI) if you want.
The reason that your plugin stopped working in Firefox 3.6 is almost definitely that Firefox 3.6 stopped supporting the XPCOM method of providing a scripting interface. Most likely, your plugin loads but you can't talk to it in javascript.
For more information, look here: http://colonelpanic.net/2010/01/firefox-3-6-has-removed-support-for-xpcom-plugins/
Also, if you need to update it, you might consider using FireBreath, which extracts a lot of that complexity away from you.
I'm putting together some virtual machines to test different browsers and I'm wondering if there is any compelling reason to be able to test the same version of IE on different versions of Windows. (i.e. IE8 on XP and Vista) I'm mostly talking about testing CSS to make sure it "looks right" across browsers, but if there were major differences in JavaScript I would want to know that too.
Are different versions of IE "generally the same" on different versions of Windows? Thanks!
The time and cost of testing different versions of windows would be better spent in other places. This would be one of the last things I would look at when looking for rendering issues.
I agree with both people who have answered previously, despite the fact that they disagree with one another.
In general, IE will act very largely the same across all versions of windows. However, there can be (and are) some occassional subtle differences. Whether these are important are not is up to you.
For the great majority of websites, I wouldn't bother with it. But for very precise web applications where you're using something like complex javascript, or if you require layout to be correct to the pixel for some reason, then it could be worth it. I'm thinking of cases where people are generating os-type applications in JavaScript where the DOM is really being pushed around, and where exact layout and flawless event-handling is critical.
Yes, I am currently testing something out and have varying results between XP and Vista.
--assuming you already have both platforms.
No, I would stick to testing on the current (IE8) and previous (IE7), unless it is a requirement to support older versions. These browsers should render the same across different versions of windows.
I personally dont bother with IE6, the sooner that is gone, the better
I would think there would be very limited cases where you'll notice a difference in IE between Windows versions. One example where you would is a Google toolbar bug I've seen in IE6 that renders html forms unusable. That bug seems to go away when you upgrade to IE8. But that problem is more Google Toolbar than IE.
Other differences you run into may be security or plug-in related. But in the default IE configurations I don't think you'll see any differences in rendering.
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.