CodeDread Blog » Firefox

FXPointer Broken – You Can Help!

Jeff — Fri, 16 Oct 2009 14:53:05 +0000

I’m writing this quick entry as a desparate plea out there: Anyone who has an hour or two and knows some XUL-fu skills, can you please take a look at my FXPointer extension? This thing worked fine in Firefox 3.0, but unfortunately some change in Firefox 3.5 causes FXPointer to completely break the location bar. Every time I’ve tried to debug this problem, I’ve failed and I don’t have a lot of time these days to work it out.

If someone thinks they can help out, please download the XPI (using a different browser than Firefox), rename to .zip, unzip and start hacking. WARNING: This breaks the location bar in Firefox 3.5 – do not enable the add-on unless you’re going to help debug the problem.

Conceptually it’s pretty straightforward. In the content/fxpointer.xml XBL file, I bind to the id=”urlbar” and then modify the onTextEntered() method.

I put the source code up on a Google Code Project to make it easier for hackers to get the source.

Put The Students To Work!

Jeff — Tue, 20 Jan 2009 22:04:59 +0000

I’m delightfully surprised at how much attention Mozilla is apparently giving SVG. First they’ve hired jwatt to work full-time on SVG. Now it looks like some students also have an interest in advancing the SVG implementation within Mozilla. Great!

I don’t have the experience of a seasoned Mozilla hacker (only a couple patches years ago), but I do know that SMIL, SVG Fonts, SVG in CSS and SVG text-specific edge cases could use some work from a SVG 1.1 perspective. Hopefully they get in contact with jwatt, rlongson, roc, dholbert and birtles and get some ideas rolling…

Houston, the SMIL has landed

Jeff — Thu, 15 Jan 2009 06:38:53 +0000

This day was five-and-a-half years in the making: the initial patch to add SMIL support has landed on Mozilla trunk. SMIL is the Open Web way of doing declarative animation, I use it on my site here and there via FakeSmile. This Mozilla patch is partial support for SMIL within SVG only (not HTML). Note that SMIL support is disabled in the build by default, as roc says “we should enable it when we’ve got enough implemented that we wouldn’t feel embarrassed about shipping it. ” – but this is a significant step forward.

Thanks and congratulations go to Daniel, Brian and Robert! Also thanks to Erik and Ian for putting some SMIL tests into Acid3. Not that this had anything to do with it. Oh, no.

Opera has supported SMIL in SVG for a couple years now. Anyone want to place bets on who will be the second to release a browser that supports it? Mozilla? Apple? Google? Microsoft? What, did I say something funny?

No Smiling in Firefox 3.1

Jeff — Tue, 30 Sep 2008 22:22:45 +0000

Poo. Declarative animation in SVG won’t make it for the Firefox 3.1 release. That’s a big shame, though I trust that it’s the right decision.

SVG Mini News Digest

Jeff — Thu, 11 Sep 2008 13:18:42 +0000

Rather than twittering these and missing a sizable chunk of people who might be interested, I thought I’d post a couple quick links to very cool news in the SVG world:

Apple finally pushed a firmware update to their iPhones that makes Safari support SVG. I first heard about it here and then Doug blogged about it.
Mozilla finally landed SVG effects for HTML, presumably for Firefox 3.1 but I’ll be keeping an ear to roc’s blog for further updates on that.
Work on the Flex SVG Viewer (FSV) has started to pick up. It is now released under the MIT license and just had its first contributed patch. More on this at a later time.
Some guy named Tim Berners-Lee chastised Internet Explorer for not supporting SVG and that article has been picked up by the Associated Press – who does he think he is?
The W3C SVG Interest Group garnered several new members within the last couple days and chatter has picked up on the Mailing List which is a hopeful sign that we’re starting to gel a bit. If you care about SVG and can help in some tangible way, I invite you to consider joining.

SVG Web Stats 2.0

Jeff — Wed, 02 Jul 2008 06:36:49 +0000

I’ve made enough updates over the past week or so on my SVG Web Stats thing to call it 2.0. Here are a list of changes:

Added ability to dynamically filter out browsers you don’t want to see in the graph (uncheck it in the legend)
Added points of interest on the graph (hover to get a tooltip, click to view the associated link
Aggregated my data to the weekly level (to smooth weekend dips out)
Added some animation to the user interface
Added tooltips to the data series for browser identification (works only in Firefox and Opera)
Collapsed some older browsers so that the graph are more distinguishable.

Drag and scrollbar performance are blazingly fast in WebKit nightlies on my machine. Just how I imagined it when I first wrote this over two years ago. Opera 9.5, Firefox 3 and Safari 3.1 performance are not bad at all. It doesn’t perform well in Firefox 2.

I just noticed that the tooltips are broken in WebKit nightlies…

Note that the legend suffers from what I consider to be a bug in Opera and Webkit nightlies. In these browsers, the legend is ‘jittery’ when the mouse hits the checkboxes. Firefox and Safari do not have this behavior because I’m using FakeSmile, a JS implementation of SMIL. It seems to me like either mouseout events are firing when they shouldn’t or the animation wants to start over at its original value instead of where it is currently. I’m hoping some Opera SMIL guru can stop by.

If you missed the link above, click here to see the demo. I’d be curious to know if it works at all in Internet Explorer with Adobe SVG Viewer. I know it doesn’t work in IE+Renesis.

Mozilla Works on SVG Effects For Web

Jeff — Wed, 04 Jun 2008 02:45:50 +0000

Very cool stuff from roc. An interesting alternative to all the CSS properties being added to WebKit. Meanwhile, Microsoft is still plodding away on bog-standard CSS 2 – expect an update from them in August, if you’re still interested (if you are maybe you want to try a new plugin for IE?)

Firefox Getting Ready To Smile?

Jeff — Sat, 19 Apr 2008 02:49:43 +0000

Chris Double was kind enough to update the SMIL patch on Bug 21642 for Mozilla and then do some builds for me so I wouldn’t have to muddle through the build and patch process. I’m ashamed to admit that so far this has been enough of a deterrant that I haven’t bothered to try it out, so I’m really glad Chris did this. The best part is that, in doing this, Chris found Firefox crashing on several tests and was able to update the patch to fix these problems.

Anyway, with the patch, a Mozilla trunk nightly gains about 4.5% to their overall SVG score. Put another way, they score 25/116 on the SVG+SMIL animation tests in the Full test suite. While this isn’t in the league of current WebKit nightlies (and neither of these platforms are in the league of Opera 9+), it does show that progress could be made on this were it applied to the trunk (once Firefox 3 ships, of course). Does anyone know if this patch means that a Firefox build would pass those SVG+SMIL tests in Acid 3?

[Update: Chris has made the Firefox builds available for download here]

[Update 2008-04-20: Chris' latest build now makes the SMIL score 38/125, though some tests have now regressed.]

Bugs From New Theme

Jeff — Thu, 21 Feb 2008 01:44:21 +0000

Sander asked me to post a list of bugs that I found as a result of working on my new theme. Here they are.

Mozilla Bugs

Bug 418164: Firefox 3 Regression: white-space:pre div forces browser window width
Bug 418305: Enhancement Request: Make Yellow-Screen-Of-Death Follow the Geneva Convention
410820: <svg> elements respond to mouse events when they should not (Not Reported By Me, But Important)

WebKit Bugs

Bug 15214: SVG link with target=”_top” opens new window (FIXED since r25729)
Bug 17423: Enhancement Request: Add support for xml:base
Bug 17424: WebKit Regression: SVG properly positioned only upon Redraw

My Own Fixes

Phil noticed that the side gradients weren’t being displayed in Opera 9.2 or earlier builds of Opera 9.5. I’ve since “fixed” that by explicitly setting the height of the divs to be 100% (with top:0; bottom:0;).
Sander reported that there was an annoying horizontal scrollbar in Firefox (also was in Safari). This was a result of me trying to get the menu to display workably in all browsers, including IE. I have since fixed this.
Sander also pointed out that the » (and «) entity is being shown literally in Opera. This is actually the right thing for Opera to do since XHTML doesn’t define any character references like HTML. I need to wrap my head around this and then either add the entity reference or update my WP theme. Haven’t got to it yet.

Is it sick that I enjoyed putting the site together and tweaking it for all the various browsers out there?

Is Firefox Sliding Down The Crap Wave?

Jeff — Wed, 29 Nov 2006 05:47:27 +0000

Apparently Firefox 2 is ignoring any style sheets that web site authors may have specified in their web feeds (RSS/Atom). It took me a few hours of idle contemplation to decide how I felt about it, so here goes.

The bug is that Firefox ignores any <?xml-stylesheet?> directive in RSS/Atom XML documents and formats the web feed representation using a default style chosen by Mozilla.

Phil Ringalda describes the workaround of padding the beginning of your XML document with a really really long comment, because Firefox’s sniffer gives up if it doesn’t find a <feed> or <rss> string within the first 512 characters. To be fair, Microsoft’s Internet Explorer 7 also does the same thing, which is one argument that Mozilla folks are using to justify the behavior.

There is a long and heated discussion over at mozilla.dev.apps.firefox about this right now. Mark Pilgrim stormed out after strongly disagreeing with the decision of the benevolent dictator.

On the one hand, web authors are screaming that Firefox should try to style their documents as they (the author) intended and that the workaround (hack) smacks of Web 1.0 days during the First Browser War where browser makers assumed they knew better than web authors.

On the other hand, the usability gurus are arguing that it is very important for everyone to “get” web feeds as a technology, including your Grandma. This means that a consistent visual representation of feeds (including subscription options) is very important and that the bulk of the stylesheets out there render the feed in a less than useful fashion. Others within Mozilla are arguing that IE7 and Google Reader also hi-jack the visual representation of web feeds, so why is everyone picking on Firefox?

These are all very good arguments, in fact, I can see both sides of the story. But I think it was this comment that finally pushed my opinion that Mozilla (and Microsoft) are in the wrong here. Here are my justifications:

It looks like if IE7 and Fx2 encounters an unknown XML stream that has a root node of <feed> or <rss>, then they assume the content type is Atom/RSS and proceed to style it as they do all web feed content. This is clearly wrong and should be considered a bug because other XML grammars may use <feed>/<rss> as their root node and will be forced to be displayed as if the content is a web feed, a clear error.
A consistent visualization is important, but what if Firefox decided that all HTML links must be blue, underlined and in 12-pt Arial font while all other text must be black, 10-pt Arial? This certainly would help Grandma realize where the clickable links are, but on the other hand if the technology supports more flexibility and the application can already handle the flexibility then overriding this behavior is stifling creativity and frustrating web authors. And yes, I know there at least an order of magnitude between ‘those who understand what a link is’ and ‘those who understand what a feed is’, but the fact of the matter is that styling is here now – once Pandora’s box is opened, you can’t close it.
From reading the comments in both the bug report and the newsgroup discussion, it sounds like this change in behavior from Firefox 1.5 to 2.0 broke some web sites. In general, I’m not too worried about breaking web sites if it’s to clean up a standards compatibility issue or because of a well-used hack that no longer applies. But in this case, the behavior change is actually quite unexpected from a reasonable developer’s point of view (“Firefox can style content using stylesheets. Here is my stylesheet, display my content the way I want!”). From their point of view, the developer followed the rules and got the shaft.

Mozilla and Microsoft should be encouraging web authors to keep their feeds unstyled for the purposes of mainstream adoption, but they should not be forcing the web authors hands. I also think for author-styled web feeds, the browsers should keep the “subscribe” button in the chrome (I’d even agree with the proposal of a tiny floating div at the top of the page), while unstyled web feeds continue to get the default visual representation that Firefox 2 and IE7 do now. Most web authors should realize that there are inherent benefits of letting the next generation browsers consistently display web feeds now that Grandmas everywhere will be subscribing to feeds all willy-nilly-like.

And the browsers should most definitely NOT be styling content that they don’t know is RSS/Atom (as told by the web server). Please, no more magic strings…