Posts Tagged ‘browser’

Firefox 3: Goto vs. Reload or Why I miss the Go button

Donnerstag, Februar 7th, 2008

As I noticed in the current trunk build of Firefox 3.0 beta3 the developers decided to change the behavior of the “go to”-button, the green one in the location bar. While it was always there and clickable in Firefox 2, it’s now only visible when you’re editing the URL. When you’re just viewing a page it’s gone.

Why is this a problem? What’s the use of it anyway?

Well, considering myself a semi-poweruser, I, of course, do not click the goto-button for visiting pages after entering the URL — at least not since the late nineties.

I use (or used) the goto-button to refresh a page I’m currently on. But there’s the reload-button for that! I hear you screaming. Right, BUT: Reload and goto make a difference in how Firefox handles its cache. I don’t know exactly how, as the page’s content is updated in both cases, but it seems Firefox ignores linked content like images, CSS files etc. when the goto is used.

To compare and validate the felt difference I installed YSlow (for Firefox 2.0.0.11 — it’s not available for Firefox 3, yet). Here are the loading times of the German tech-news site heise online, first using the goto-button then the proper reload:

heise Speedtest Goto

heise Speedtest Reload

My plea to the Firefox devs: Either…

  • give us the old behavoir back and show the goto-button permanently.
  • or offer an option in about:config to choose.
  • or fix the reload-button to offer “fast-reloading”, too. Maybe F5 = fast reload, Ctrl-F5 = full reload as it’s in IE IIRC.

Thank you.

PS: Other than that Firefox 3 really rocks. Even in beta and with unauthorized addons it’s more stable than 2.0.0.x :)

OpenID browser integration with auto-login through whitelists

Samstag, Dezember 15th, 2007

Thinking about whether OpenID is capable of true single-sign-on I came to the conclusion that it’s probably not designed for this, but that browser integration could provide an almost similar experience if there was a standard for this. So here’s my question.

(Note that I know of Verisign’s Seatbelt and Sxipper. But both do not offer what I request here, AFAIK.)

Dear lazyweb,

is there a project or standard proposition that aims to (or even an implementation that already does) enable OpenID browser integration in the following way?

  1. let the user create a whitelist à la “always use xyz.myopenid.com for foobarsite.com”
  2. let the browser use this whitelist to send a standardized cookie or HTTP-header to the relying party site on each request (or only when no standardized and valid session cookie exists)
  3. on receiving such an request, the RP should automagically start the authentication process — and finish it transparently for me if I’m logged into my OpenID provider

This would be a huge step forward, I think.

Firefox’ http.use-cache is evil (sometimes)

Montag, März 5th, 2007

Ich habe mich eben fast zwei Stunden am Apache totkonfiguriert, bis ich gemerkt habe, dass der Firefox einen einmal fehlgeleiteten Redirect (es sollte von fuubar.de nach www.foobar.com weitergeleitet werden) auf ewig gespeichert hat.

Mit network.http.use-cache auf true, was die Default-Einstellung ist, macht sich Firefox nicht einmal die Mühe, zu gucken, ob sich an dem gewünschten Dokument etwas geändert hat. Dann hätte er nämlich mitbekommen, dass der Apache inzwischen ganz woanders hin verweist.

In Zukunft werde ich diese Option nicht erst nach zwei Stunden in Betracht ziehen. Dafür habe ich wieder einiges vom Apache gelernt, was mir bei schneller Ursachenfindung natürlich verwehrt geblieben wäre *hust*.