| Date: | May 19, 2006 / year-entry #174 |
| Tags: | non-computer |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060519-17/?p=31123 |
| Comments: | 12 |
| Summary: | I successfully avoided the stealth sidewalk the other day. This evens the score. (Today is Starbucks Bike to Work Day.) |
I successfully avoided the stealth sidewalk the other day. This evens the score. (Today is Starbucks Bike to Work Day.) |
Comments (12)
Comments are closed. |
I have heard many entertaining excuses, but blaming the sidewalk for your inability to ride a bicycle(in your "On being attacked by a sidewalk") takes the cake. It sounds like you are getting better at riding a bike, but just in case I have included a like to some handy-dandy tips: http://www.helmets.org/kidteach.htm and http://www.sheldonbrown.com/teachride.html
Starbucks Bike to Work Day:
"Throughout Puget Sound, riders can stop by Commute Stations to pick up free schwag…"
The only time I crashed my bike into the sidewalk I was under the influence of schwag. Just say no.
I rode my bike into work today (taking the bus up the big hill on 520). I’m very out of shape and going home isn’t going to be to fun, but I plan to keep doing this for a while.
I guess I’m not seeing what I’m supposed to be seeing. There’s a road that suddenly divides. The median looks like it has a curb, looks like it doesn’t have a warning sign sticking up out of it, and looks like it could be dangerous to anyone riding along there at night who didn’t know about it before. But it doesn’t look like it has a sidewalk in it, as far as I can see.
I ride my bike to work nearly every day. A few times a combination of rain and wind persuaded me to walk instead. Oddly I don’t recall the last time snow persuaded me to walk instead, though some years there’s enough snow to be persuasive. So why isn’t there a Starbucks along the way? Sigh.
Don – politeness costs nothing.
From what I’ve gathered, helmets aren’t mandatory in the US? Is that right?
lachlan,
That’s right. It seems neither are stop signs for bike riders… At least not the normal ones I see (kids).
If i understand Raymond’s initial post correctly, in order for the arial photo to make sense, you need to switch to the north faceing photo. Click the N in the legend (upper left-hand corner).
Raymond was heading north on 172nd Ave NE (the road going from the bottom to top of the photo). South of the intersection with NE 138th St. (the intersection in the center of the photo) there is no sidewalk by the side of the road, just asphalt.
North of the intersection this area turns into a sidewalk. You can see the now infamous curb, curving up to the zebra crossing.
Well, I would hit that N in the legend, if I could see anything other than a blank screen and a warning about some JS taking too long to run…
(I bet it works in IE, right? Oh, of course it does. Sigh. Heaven forbid we actually test with a browser other than IE when we make our huge changes. (It worked in FF about a week ago, before the look changed.))
Hm, suppose web site X encounters timeout errors. Do you assume
1. Web site X is under heavy load.
2. The authors of web site X don’t support your browser.
Live Local works fine for me in FF just a half hour after your comment.
Note also: If you’re going to make a snarky comment about Live Local, why not post it to the Live Local blog? Complaining to me won’t accomplish anything.
I only viewed Live Local in Firefox, so i don’t think thats the problem.
Jeez, I feel stupid now.
Turns out it was because the site is trying to set window.title, where before it apparently wasn’t. (Or something.) I had disabled that functionality using FF’s policy system (basically, you can enable or disable access to every JS property, both get and set) way back when the FF "long title" DoS was new. (That was the workaround at the time, because any known exploit required script to set window.title.)
And I still have it disabled.
I ran into a problem with Google maps several months ago, but at least that gave me a JS error about "access denied to set HTMLDocument.title", which pointed me in the right direction because the prefs.js entry to disable that functionality was named "capability.policy.default.HTMLDocument.title.set". So I looked into the capability documentation and found out that I could have an entirely separate policy that allowed window.title set operations, then I could assign individual sites to that policy. So I created a policy and assigned maps.google.com to it. That fixed the problem there.
Then, several months later, I run into this. But I don’t see any JS errors (just some warnings that are fairly standard for most JS files), so it wasn’t very obvious that the problem was the inability to set window.title.
But, I added local.live.com to the list of sites in the policy that’s allowed to set window.title, and it started working.
So. Sorry for the false alarm, and the stupid commentary that went along with it. That’s what I get for assuming the problem is on the other end. :-(
Best of the text i read about a problem.