|
title: Put the knife down and take a green herb, dude. |
descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001. |
|
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike, always wear white. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green. |
|
|
x
MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include...
You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now! |
|
| Monday, October 31, 2022 | |
|
Amazingly (or perhaps not), Firefox (macOS 106.0.1 (64-bit)) slammed me back to using Google as its toolbar search engine. I had been using DuckDuckGo for years. Luckily Firefox had a pop-up telling me as much, actually bragging about it, so I knew to set it back. But I did test it once before swapping, and this was not a drill. The update to Firefox wasn't showing me the wrong dialog; it had slammed me back to Google. /sigh Profiteering weirds the internet. Labels: firefox, Google, hats o' money posted by ruffin at 10/31/2022 09:09:00 AM |
|
| Wednesday, June 29, 2016 | |
|
This page about Firefox claims:
That's so not Scottish, it's crap. In case you think I'm overstating, or screwed something up, here's my full Firefox history (full disclosure: I've erased about 12 pages between "Internet for people, not profit" and the Yahoo search for AAA that'd tell you what bank I use): I can tell you, I haven't opted in to giving out my location everywhere in those pages. And when we check Explain that, Mr. Mozilla Privacy is Job 1. (In other news, AAA still uses WebObjects.) EDIT: Run the EFF's Panopticlick page now. I always kinda wondered about this (if you get all my browser metadata, you'll kinda know who I am, won't you?), but it's scary to see it in practice. Even worse is learning about this canvas fingerprinting, which is a much more specifically identifying source of metadata that I had no clue existed. /sigh They know exactly who you are. Labels: fail, firefox, geolocation, privacy posted by ruffin at 6/29/2016 10:27:00 PM |
|
| Tuesday, April 19, 2016 | |
|
Sometimes, code smell comes from your documentation:
Giving invalid data until "the browser will give up" is a best practice, is it? Whew, that smells. I love the, "The trick is to really force" line. "Really force"? "Hey, Firefox, remember when I told you to turn off autocomplete? It's just an informal request. If I want you to really honor it, I'll really force you to." /sigh Protip for Mozilla: Firefox form autocomplete is broken. I don't really care if it follows standards; most users and nearly every web developer will tell you its behavior is broken. I hate to see [sic] it, but it looks like Firefox usage may be down over 12% over 2015. It was my favorite browser to use for dev and home. I think the trend is pretty clear: There are now only three browsers. Edge/IE on Windows, Safari on iOS (and OS X, if you count it), and Chrome. posted by ruffin at 4/19/2016 10:56:00 AM |
|
| Monday, March 02, 2015 | |
|
As I've mentioned before, there's no way Yahoo's gains in Firefox search sticks. It took me one search to get disgusted and swap back. I imagine others will have the same reaction with a little less immediacy. No offense, Yahoo, but Google has search down cold, as long as Superfish hasn't infected your box[1]. Better results, huh? By what metric is that measured? I don't even dislike Yahoo. I just don't think it's cool to slam users who are happy with whatever search provider they selected already. I will back down just a touch (as I may have mentioned before) if this only happens if you never swapped search providers. My iMac at home and my work box are pretty new, and I don't recall if my MacBook or Lenovo acted slammed or not (I've flirted with Bing on both a few times over the years). But if Firefox swapped *everyone* to Yahoo, not just those who'd been using Google because it was the default, well, that's unavoidably a slam. Anyhow, now with image. Yay. [1] RLY Lenovo? I'm still getting over that idiotic move. posted by ruffin at 3/02/2015 04:48:00 PM |
|
| Tuesday, February 03, 2015 | |
|
From StatCounter as recounted by Gruber:
There's no way that lasts. I wonder what percentage is permanent. Firefox hijacked my search bar at some point in the recent past, and after trying a single search, I was setting Google as the default search engine, peeved at the audacity of the sinking Mozilla ship to change my setting without asking. Maybe on that box I'd never swapped from Google as my default, but I certainly have played around with Bing on other Firefox installs and quickly gone back to Google. Other folks will probably go more than a single search before getting upset enough to learn how to swap their engine, but eventually they'll notice Yahoo ain't as good as what they had before, and ask their tech-savvy friends to swap them back. I hope. Man, can you believe it if 19% of Firefox users, already probably a slightly above-the-mean group of techies, just don't care, and figure the default search engine is always good enough? More telling is probably, if Firefox hijacked everyone like they did me, that over 70% of Firefox users immediately swapped back to Google. posted by ruffin at 2/03/2015 07:01:00 PM |
|
| Thursday, February 13, 2014 | |
|
It appears Firefox is going to have what are, for now, non-intrusive ads that fill up your "frequently visited" tabs on an empty page with some adverts until you visit enough sites, as if those were helpful suggestions.
There's a painful irony in reading this shortly after DaringFireball linked to a post from a former RealNetworks employee explaining how adware was forcefully driving RealNetworks' business: My manager then said, โMore than half the company would have to lose their job in order for us to stop these tactics โฆ so are you volunteering to be one of them?โ I understand making money from having Google as your default search engine. That's an easy win-win. Google seems to offer the best (and if not the best, no worse than top two, and you'll have to pick who the other is) search engine, folks enjoy the simplicity of a search box/unified search bar, and you might as well pocket the cash for giving the bar to them. But don't try to link this new ad grab to the search bar, as if Google was going to stop paying, which the originally linked news item about Firefox's new ads does: Mozilla is heavily reliant on income from search royalties from Google, and has been for some time, so this would seem to be an exploration of other financial options โ with possibly more alternative revenue streams to come? That stream simply isn't drying up. How much do you think Bing would pay to be on Firefox? Everything I can tell from the rumors surrounding Microsoft now that they have a new CEO suggests that they're going to be less Windows-first-and-Windows-only than they have been in the past. And it's not like Bing was a stranger to search bars before now either. There's plenty of revenue to keep Mozilla afloat without becoming the next RealNetworks, and only so many places where you can put ads without becoming intrusive. And hopefully only so many times you can insert ads before someone starts building Firefox without them. See Banshee, the crossplatform iTunes replacement -- there's been a small tempest about how its affiliate fees for music purchased through its UI at Amazon get rerouted on different Linux distros. It's not that hard to "re-monetize" software. We've been happy to give Firefox a few dollars to provide us with better functions. If you want more cash, innovate with new functions, dang it. Or you might be surprised how quickly your users' goodwill dries up when you start demanding more tribute. Labels: firefox, Google, hats of money posted by ruffin at 2/13/2014 08:05:00 AM |
|
| Monday, January 13, 2014 | |
|
Firefox world loses Web dev guru to Chrome | Deep Tech - CNET News: Dion Almaer, who had worked on developer tools at Mozilla earlier in his career, noted the significance of [the lead Firebug programmer in 2011, John J.] Barton's new job in a blog post today.I'm often a "if it's not broken, don't fix it" kind of guy (not a huge limitation, since my threshold for entering "broken" state is horribly low), and have been using Firebug as my first-line tester for years. I mean, heck, my code has to work in Firefox, so at worst, I'm only losing time that Firebug is worse than Chrome's tools (and that Firefox is slower than Chrome). That is, code has to work somewhere first. Why not Firefox? But recently, I've heard too many good things from Chrome-first guys about Chrome's tools, have noticed that our app works insanely quicker in Chrome than Firefox, and am getting a little tired of seeing the "Warning: Enabling the Script panel causes a Firefox slow-down due to a platform bug. This will be fixed with the next major Firefox and Firebug versions," error at the top of my Firebug console. I usually use Chrome when hitting our production testing server, and thought maybe it was time to test it as my dev choice instead. (And, honestly, I had some trouble with Chrome keeping its cache clean/empty when I last tried -- even when set to no cache, it would occasionally cache jive, which made it much too easy to waste time testing there.) When Googling how to transition from Firebug to Chrome's tools, I ran across the above post. That's kinda strange -- I haven't felt Firebug was horrible, though I think I've seen a native Firefox equivalent pop up sometimes when I hit the "right wrong" key combination. Anyhow, this is just to say I need to catch up with the state of browser debugging. Firebug is great, but it's probably past time to come up for air and see if the transition cost to something else isn't worth it. posted by ruffin at 1/13/2014 10:58:00 AM |
|
| Friday, August 23, 2013 | |
|
Gosh, I'm an idiot. Would have been nice to notice that button ("Show Command Line Popup") on the Script tab, well, YEARS AGO. posted by ruffin at 8/23/2013 09:35:00 AM |
|
| Monday, August 06, 2012 | |
|
WebKit Isn't Breaking the Web. You Are | Webmonkey | Wired.com: We at Webmonkey hope itโs obvious that building WebKit-only sites is a waste of time. If youโre only interested in iOS users then take a tip from Instagram and build a native app. Let's just quickly say that's crazy advice, and it misses the point of Glazman's critique. If you don't know Objective-C, by all means, leverage what you do know if it'll make a strong HTML5 app for mobile devices. Use PhoneGap. Enjoy. No guilt required. Seriously, if you can't code HTML5 for other browsers you need to learn to code Obj-C in Xcode? Insane and inane. The point is that those who use HTML5 shouldn't use browser-specific prefixes. Not sure how I feel about that either. If one browser (or rendering engine) is so far in front of another, then it's going to "win" the adoption war. Examples are written with webkit prefixes, they're copy and pasted, seem to work okay for their intended browser, and we're done. It's a non-trivial expense to learn that webkit isn't a standard if you're a gunslinger. (I'm not arguing we should be gunslingers, but that browsers should realize they exist. LOTS of them.) If the other browsers support those CSS standards with their own prefixes (and with standardized ones), it's a heck of a lot easier to have the browsers support the different models than every programmer. Any time you're asking a programmer to write something twice to do things right (really, I'm pretty tired of if (document.getElementById) { branch1 } else...), you're doing it wrong. Get the cheese off of your face. Normalize. Put the logic where it belongs. To be clear: In this case, it means Firefox needs to get over itself and chase WebKit. IE might follow. Do we care? It's an ivory tower versus the market issue. You can't control programmers absolutely. I, in theory, like where Glazman is going. And in practice, just mentioning it will lessen the issue. Let's just stop pretending it's a zero-effort change for programmers to write platform neutral code and, therefore, as long as browsers are less than 100% equal, you'll always have a percentage of the code in the wild that supports one over the other. Degrade? Sure. Write to treat each version of each browser equally? Impossible. [sic] posted by ruffin at 8/06/2012 09:02:00 AM |
|
| Wednesday, June 13, 2012 | |
|
Firefox Disable / Hide New Tab Page: HowTo: Turn this feature off completely
Thank you. Labels: firefox, noteToSelf posted by ruffin at 6/13/2012 01:43:00 PM |
|
| Wednesday, June 06, 2012 | |
![]() Okay, do we think that was an accidental/cutesy inclusion of a Diablo ordering page on the Top Sites explanation page or a paid advertisement? My kneejerk was the former, and about 5 seconds later I started thinking the latter. Labels: blizzard, firefox, hats of money posted by ruffin at 6/06/2012 10:28:00 AM |
|
| Thursday, April 07, 2011 | |
|
If you use the Add-On Manager to create the foundation to your Firefox extension, you might see that your description is literally "description" even though you've got a different value in <em:description> in your install.rdf file. You've probably got this line in overlay.properties: extensions.zoteroplay@genreacrossborders.org.description=description (where zoteroplay@genreacrossborders.org will be the id of your own extension) That'll do it. /sigh The property "covers up" your longer description in install.rdf. Erase that line and your other description will show up. Labels: extension, firefox, problem solved, XUL posted by ruffin at 4/07/2011 07:13:00 PM |
|
|
More fun code! Note today's new lessons -- the OM for tree items, rows, children, and cells; the use of CDATA for encapsulating javascript in XUL files, which are picky XML files, especially when you use a <; and slightly more situation-specific code. 1 <?xml version="1.0"?>So this ends up looking like the following (after rows have been added to new and dupe sources several times): ![]() It may also be useful to note that I made the sidebar open up apparently about as wide as Firefox is going to let it with this code in ff-sidebar.js: 1 var mainWindow = null;Labels: extension, firefox, problem solved, XUL posted by ruffin at 4/07/2011 01:18:00 PM |
|
| Tuesday, April 05, 2011 | |
|
I hate to say that I'm not real impressed with the state of tutorials on building Firefox extensions, in part because that seems to imply some sort of incompetence of my own as a coder. I mean, come on, thousands of folks are building and releasing these danged things. It's obviously not rocket science. But the bottom line is that much of the extension building process is still left in trial and error land where it could easily be put into tutorials. Lots of folk are banging their heads, as far as I can tell, on the same stuff, and there just isn't a large enough community to put all those individual lessons learned together for the collective to benefit from. Anyhow, so I've struggled today with how to build and then programmatically access a sidebar made in XUL for a Firefox extension. I want to populate it with the results of a Zotero database installed within the same Firefox instance, but before I do that, I just want to be able to 1.) display the sidebar 2.) display a tree in the sidebar and 3.) add rows with information from my "main" javascript file that's sent over to the sidebar. Here's some fun. The best XUL and Firefox extension building code probably comes from Add-on Builder. Slap in your description, etc, and select it all. It'll create a toolbar, button for your main toolbar, a menu item in tools, even a context-menu (the one that's typically displayed when you right-click a web-page displayed in Firefox) for you. Voila. Perfect. 90% done. ![]() Then we learn most of the important stuff from this thread at Mozillazine. I pasted this into ff-sidebar.xul based mostly off of the info at the above link: 1 <?xml version="1.0"?> So that gets us a sidebar with a tree in it. To see it, you load up the extension that you've built (we're assuming you already know how to unzip an xpi and hack the files in it to install later -- or to have Firefox change live), and use code like this in your "main" javascript file (overlay.js in the Add-On Builder code) to call the functions in the sidebar. So one place would be to slap what's below into onToolbarButtonCommand in overlay.js to make the magic happen. 1 // Get the sidebar that's currently displayed in the browser. So now we can access a javascript function inside of the sidebar code and have it add a row programmatically. Of course, the trick is that we're using that "children_root" id in the treechildren element, which really speeds things up and simplifies what we're doing. Now, honestly, the best way to add programmatic rows/rows at run time would be to write a Custom Tree View that has the info I want sitting in a giant array or something silly like that. With enough children (that is, I'm going to be displaying books with authors, titles, publishers, etc), this'll get downright messy, and I might end up cheating and using another control from the XUL periodic table (Note: That periodic table link doesn't work in Firefox 4+ without installing an extension that re-allows Remote XUL (this one should do it, I think); I'm using Camino to view the chart for now). ![]() Ah, sweet proof of concept success. But that's the start. And I thought I'd left behind the craptasticness of model building when I took a Java break. No such luck. Labels: extension, firefox, problem solved, XUL, zotero posted by ruffin at 4/05/2011 05:19:00 PM |
|
|
| |
|
|
All posts can be accessed here: Just the last year o' posts: |
|||||||||||||||||||||
|
||||||||||||||||||||||
|
|
|
|