IRC Log Viewer » #firebreath » 2010-11-01

IRC Nick Time (GMT-7) Message
iaincollins 03:11 hey Plasma_
If you install WiX the build process will spit out an MSI file which will install the plugin (and register it for you)
That said, using regsvr32 *should* make it visible to Firefox, Safari, Chrome, etc (unless someone wants to jump in and correct me)
If you are using Firefox might want to view about:plugins (which should also cause it to look for new / updated plugins)
Plasma_ 05:11 iaincollins; thanks I managed to fix it a bit earlier (10pm here now!) and left the pc
a few things made it break for me, 1) I renamed the plugin to drop the 'np' prefix (seems its needed), and 2) I was using my own installer that just regsvr32'd - I found some reg keys I need to add (HKCU\Software\MozillaPlugins\...) for gecko browsers to pickup the plugin (chrome/ff) and that fixed it
iaincollins 05:11 Oh cool, yes, was going to mention the np thing (it's mentioned in the docs somewhere, but it got me too)
probably worth having everything like that in an FAQ as I'm sure lots of people go through that process
if you are intersted, I can suggest some changes to the WiX installer that make it more usable to deployment
Plasma_ 05:11 yeh already using 'advanced installer' to take care of it (its an existing app, so its an existing installer with logic for other bits in there already)
so I just looked at the fb one to see what it was doing as a reference too
iaincollins 06:11 *to/for
oh cool
taxilian cautioned me again using regsvr32, there was good "regsvr32 consider harmful" type article he pointed me to
(a list of 10 reasons why it's problematic, even though it's used all over the place)
I have wrapped my .MSI file in a custom setup.exe, which takes care of invoking it with flags like /qn /passive as required;
but that's really just a kludge to stop the "you need to close/restart these applications" dialog
(because in my case, I don't ned to)
really I have to delve into WiX to understand what's going on better :)
Plasma_ 06:11 my eyes glaze over when I think its a simple task and theres like 1000 options to get things working heh
really appreciated the fbgen tool :p
outta here for the night, catcha
taxilian 08:11 iaincollins: thanks for heling Plasma_; I glanced at the logs and saw that he'd dropped in yesterday, hoped he'd come back when someone was here =]
iaincollins 08:11 no worries :) I went through exactly the same things he's done
"wait, it looks like having 'np' as a pefix actually matters" and then "oh yeah, it's in the documentation"
taxilian 08:11 want to update that in the FAQ on the website? =]
iaincollins 08:11 good plan :) will do that today
taxilian 08:11 thanks
(I find I get more done myself on things that are more important if I do my best to foist off anything that can be foisted onto someone else :-P)
iaincollins 08:11 totally :)
Just out of lazyness, do you know what it is that triggers firefox to know it needs to restart when a plugin DLL it's using is uninstalled?
taxilian 08:11 nothing triggers that
iaincollins 08:11 I expect it's something internal that just notices a resource it was using has just vanished
taxilian 08:11 nope
if it is actually using the dll, you can't delete it
the best you can do is mark it to be deleted on the next system restart
iaincollins 08:11 I'm using a (only slightly) modified MSI
yeah I was thinking of doing that
taxilian 08:11 the MSI might even do it by default; not sure
wtih NSIS it's pretty easy, guessing with WiX it's not bad either
iaincollins 08:11 when I upgrade Firefox notices (but only if the Plug-in DLL is actually currently in use)
taxilian 08:11 you can also rename the directory, but that causes firefox to crash eventually
maybe that's a new feature, then, in 3.6
iaincollins 08:11 will avoid that then :)
could be, I've only been testing with 3.6 actually (to keep things simple for now)
taxilian 08:11 my practice has always been to delete the DLL if possible, if not just mark it for deletion and put the new file with a different filename
since I use the filename to determine the version that's usually a good way to go
but I have never known Firefox to tell me it needs to restart because something was uninstalled
iaincollins 08:11 oh you do that with the filename too? that's reassuing
taxilian 08:11 I think I figured out later that I could get away without doing that if I put each version in its own directory, which eventually I had to do to fix another bug
iaincollins 08:11 yeah it was the only browser doing it(out of IE, FF, Safari, Chrome)
taxilian 08:11 but initially that was the easiest way
never seen that
iaincollins 08:11 I'll take a screen grab for reference (the changes to the installer are currently just upgrade any version to this version; downgrades allowed)
not a problem, just curious
taxilian 08:11 for me that may be a problem someday... hmm
good to be aware of, though
this is one reason I love this project; I learn a lot from the experiences of other people
and it's always good to have a reputation as someone who has seen or heard of just about everything that happens =]
iaincollins 08:11 :)
I tested here on two Windows XP installations, Windows Vista and Windows 7 (both 32 bit)...
taxilian 08:11 so under what conditions exactly did the message show up?
iaincollins 08:11 when I got home I fired it up on Windows Vista and Windows 7 (both 64-bit) machines
and it only worked in IE (had to fix some bugs, that was another story)
So, I have to have the browser runnning, with previous version of the plugin installed AND it has to have loaded the DLL in the current session.
I am (currently) changing the mime type, dll name and file version with each release
(primarily to aid in debugging at this stage)
the MSI is set to upgrade (removes the old package on install of the new one)
and this was only on Windows (I have not tested the upgrade path on any other OS) but occurs on Vista, Windows 7 and Windows XP, all Firefox 3.6.x
taxilian 08:11 interesting... does Firefox just pop up a dialog as soon as the old DLL is removed?
iaincollins 08:11 I'm not sure, I'll replicate it now
So, to confirm, I'm ONLY seeing it *if* the plug-in is "in use"
and this what I'm seeing:
taxilian 08:11 as in currently in use?
on a page?
iaincollins 08:11 yeah, I'll just see if it happens if it's also in memory or not
taxilian 08:11 I don't think that's firefox
iaincollins 08:11 (I mean, already loaded but not in use)
taxilian 08:11 but I could be wrong
what happens if you just try to delete the file by hand?
iaincollins 08:11 not sure, will try
taxilian 08:11 I'm thinking that may be something your installer is doing somehow
maybe WiX automatically sends a request quit command to anything trying to use the file
iaincollins 08:11 yes, just about to say, so I have a setup.exe which installs the .MSI (it may ultimately install more than one)
taxilian 08:11 see, I have a hard time imagining that Firefox is doing that, because by normal windows rules you can't delete the file while firefox is open
iaincollins 08:11 I think it does yes, the setup.exe runs the MSI with /quiet /qn (IIRC) as in "don't prompt" and "minimal UI"
taxilian 08:11 rather while firefox has the .dll open
so if you can't delete it, firefox can't detect that you deleted it
iaincollins 08:11 if I run the MSI normally it prompts me to restart the open browsers (and lists them by name; presmuably just a list of things that have loaded any resources it's trying to uninstall)
taxilian 08:11 ahh
iaincollins 08:11 I have seen this message with MSI's for .NET packages too, and written custom actions around it, I think it's an MSI specific thing
taxilian 08:11 then yes, I imagine that when you run it "quietly" it just tells them all to quit
did it do that automatically or is that something you added?
iaincollins 08:11 no it's 'automagic'
taxilian 08:11 really? and it prompts for open browsers?
iaincollins 08:11 I was curious what it was and was wondering if you knew :-)
yeah, I'll take a screen shot for reference
taxilian 08:11 that's really baffling... how would it know that it should be looking for browsers?
and how would it know what processes qualify?
iaincollins 08:11 I am guessing there is a way of seeing 'who is using this DLL'
taxilian 08:11 you're certain this is in the MSI? and isn't something you added in customizing?
that could be
iaincollins 08:11 no I've definately not added anything like that
actually, you get almost the exact same dialog if you remove any MSI and have the application running (and the developer has not written a custom action to check the app is currently running)
I know because I've got that issue with a systray app of mine (bah)
taxilian 08:11 that makes sense, then
not a bad thing, per se
if I were you, I would change it to say "delete this if you can and flag it for deletion if you can't"
not sure how to do that
but I'm certain it's possible
iaincollins 08:11 yes I think that seems very sensible, I am not sure either but I keep seeing references to doing it :)
I will investigate!
taxilian 08:11 huh. that's actually kinda cool
iaincollins 08:11 and it seems to happen there with a plug I've loaded on a page previously, but am no longer on (no other FF windows open there)
the browsers handled it gracefully actualy
taxilian 08:11 presumably because firefox hasn't unloaded the module yet
iaincollins 08:11 yeah
note that trying to close the browsers usually fails (it gets stuck for about 10 seconds then gives up, some times some of them restart)
that seems consistant on every platform :) (am sure it's an MSI thing)
taxilian 09:11 must be
neilg_ 09:11 taxilian: In regards to your email, I was going to suggest Dr. Dobbs but then saw you'd already thought of that. I would also suggest Develop, Gamasutra and perhaps Make magazine too
Also: Hello all! lol
taxilian 09:11 all magazines that I'm not familiar with =] thanks
taxilian 10:11 anyone have any idea how to submit an article to Dr. Dobbs? I can't find any info on it anywhere
shales 11:11 hi
I'm thinking about developing a browser plugin but I'm still at the point of not knowing what is technically possible
can I package another executable with a plugin and start and manage another process from the plugin?
taxilian 11:11 yes
but it's a bit of a pain
shales: The main challenge you have is working in IE on vista/win7 in protected mode
you have a low integrety process, so if your main executable needs to be a medium integrety process (so that you have file system access, etc), you'll have to register it as a medium integrety process exectuable when you install for info on working in a low integeity process
shales 11:11 hmm, I'm not familiar with low/medium integrity stuff. This is part of vista/win 7?
taxilian 11:11 for IE specific info
shales 11:11 k, thanks
taxilian 11:11 in short, it is the bane of your existance
but it's doable
shales 11:11 hehe, yeah sounds like a pain already
taxilian 11:11 make sure you develop whenever possible on a vista or 7 machine w/ UAC on or you won't see the bugs until you test later
we really should create a wiki page on IE protected mode issues
taxilian 12:11 be back later
shales 12:11 ok, I think I can keep all of the local data I need inside %userprofile%\AppData\LocalLow or somewhere like that that the low integrity process can access
do you know if it also restricts UDP and TCP connections on the local network?
msdn seems to say sockets would be blocked too
or maybe not. says sockets are allowed.
taxilian 12:11 sockets on localhost are allowed
named pipes are allow possible for inter-process communication
I have used both successfully
shales 12:11 the more I read msdn, the more I'm tempted to forget about making an ActiveX control and stick to NPAPI plugins
neilg_ 12:11 It's tough. It's a problem I've been working with too
shales 12:11 tell me if this is crazy: package couchdb with a plugin, the plugin itself reads the local filesystem and sends UDP and TCP to machines on the local network.
taxilian 12:11 hmm. sounds pretty crazy to me. that doesnt' mean you couldnt' do it
what is the goal, though?
neilg_ 12:11 You could do it, you just couldn't write to many directories from within that plugin
taxilian 12:11 (first of all keep in mind that packaging erlang in a plugin could be more than a bit tricky)
neilg_ 12:11 You'd get prompted by most firewall software though
taxilian 12:11 also true
neilg_ 12:11 Ugh, that's horrible grammar
shales 12:11 yeah, packaging couchdb is a challenge in itself
taxilian 12:11 if it were me, I'd aim for more of a "install them together and activate from the plugin" type experience, though I'm not sure why you'd need access to a couchdb instance controlled by a plugin
shales 12:11 the goal is managing a media library that catalogues all the media you have on your machine, in your local network and favourited from online sources
taxilian 12:11 ok; that doesn't seem like it should all live in a plugin, though I guess I can see why you might want to use a plugin to access it
neilg_ 12:11 Seems like a plugin isn't for you then? Not that you couldn't do it with one - you could
Just sounds like something that should perform a HTTP POST rather than presiding within a plugin
taxilian 12:11 yeah; you can install couchdb on the local machine and just talk to it using AJAX and javascript
shales 12:11 "not a plugin" could be the right answer
taxilian 12:11 keep in mind that in general, if you have to look for excuses to use a plugin it probably isn't the best architecture for you
shales 12:11 neilg_: HTTP POST to couchdb you mean?
taxilian 12:11 that's what I'd look at doing
neilg_ 12:11 I'll admit that I wasn't thinking of that initially, I was assuming (yes, this is a bad habit of mine) that you want to push the data onto the web. But you could absolutely do that too.
shales 12:11 I got to the use a plugin idea by starting with a web app and thinking about what I need to also index the media that's available on the local machine and in the local network
neilg_ 12:11 But if you're creating a process that's going to listen on any port then most personal firewalls are going to complain about that which may scare customers
taxilian 12:11 unless you only care about access from localhost
shales 12:11 the couchdb would only listen on localhost
taxilian 12:11 ok; the couchdb thing is a question of architecture. I think you'd be crazy to try to put couchdb in a plugin
it's not designed to work that wya
in point of fact, you might be crazy to even try to use it with this type of a system; I realize that couchdb is pretty cool, but it's not exactly small and portable
neilg_ 12:11 That's true, I'm just not certain that firewalls wouldn't complain anyway but then when I run a personal firewall it's because I'm very neurotic and set it up to complain about everything unusual ;)
taxilian 12:11 if it were me, I'd use something like sqlite
neilg_: in my (pretty exhaustive) tests, opening a port on localhost doesn't cause any firewalls to complain
shales 12:11 It does seem hard. It's not essential. I just wanted to use it because it gives me easy database replication
taxilian 12:11 shales: Yeah, I understand that. I use couchdb for several projects myself
but I would definitely not recommend putting it in a plugin
shales 12:11 was also planning on embedding sqlite and using it as a sort of cache for the data in couchdb that can be easily searched
taxilian 12:11 and it seems like overkill to install a DB server just for one app
I would use sqlite and roll your own JSON based replication; it doesn't sound like you need anything along the lines of the power of couchdb
but that's just me
shales 12:11 yeah, I agree. will look at other approaches for data replication
neilg_ 12:11 taxilian: That's pretty useful to know! That would make using 0MQ pretty interesting
taxilian 12:11 neilg_: that's why FireBreath 1.4 has an embedded web server
allows us to designate a zone that is virtually impossible to spoof that has special access to APIs that aren't normally available
shales 12:11 what's the embedded web server for? is there something on about it?
taxilian 12:11 it's in the dev branch
not yet stable
still experimental
I'll get around to documenting it eventually
the idea is that you use JSAPISecure (also in 1.4, dev branch)
and you can set a security level on different methods and properties
i.e. set them to "protected" and define protected as anything from a "trusted" subdomain
so that they can't be used elsewhere
then for really sensitive APIs that could be used to collect personal data, you only allow those when accessed from localhost
and the localhost stuff comes from the embedded web server
so you have complete control over what goes into it
the way I'm using it is to then proxy a "whitelisted" path (something like /pluginroot/) to a specific location on a secure webserver
so even though they can detect what is going on to that server, they can't spoof it because it's using SSL
and since the whole page is coming from localhost, nobody can inject anything into it
well, gotta run to class now. back in a few
shales 12:11 ok, bye. thanks for the explanation. still digesting it
taxilian 18:11 crap. so I found another breaking change that should probably be made :-/
maybe instead of making a breaking change I'll fudge it so that the old way works and is just deprecated; that might be doable
kalev 18:11 I'm fine with breaking changes, but I guess keeping deprecated API around for one release cycle might be useful
taxilian 18:11 I really dislike anything that makes people less likely to upgrade
because I refuse to support old versions =]
kalev 18:11 What's the change you are planning?
taxilian 18:11 making the event system use weak_ptrs instead of normal pointers
I have a case where I need to communicate between two plugin instances
kalev 18:11 Sure, sounds like a good change
taxilian 18:11 yeah, I thought so
testthingy 23:11 wow; javascript based IRC client. cool. (taxilian in disguise)
taxilian 23:11 testthingy, you are awesome
testthingy 23:11 yes, this is hard to deny
taxilian 23:11 now go away