Google.com is broken in Firefox 3.6.3

[Garrett Smith]

I am experiencing a lot of problems using google.com search results,
GMail, and google groups today. I am using Firefox 3.6.3 with all
javascript enabled.

Tonight I am getting errors that are numbers:

".206"
".206"
".104"

Indeed it in the source, I see:

| throw new Error(".104");

The layout for... wait. I am getting the OLD layout now. Haha, yay they
finally fixed it. JUST NOW, as I type this message.

Apparently somebody totally screwed up and broke Google.com search
results. Took em all day but they finally fixed it, but I swear, all of
today, the layout for the search results page showed the google "sprite"
image overlapping the search results, making it very hard to read the
first two results.

Too bad I did not get a screen shot of that.

It is amazing and pitiful at the same time. Google is a major tech
company, Firefox is a great browser, the page should be really simple to
make, just HTML, CSS, and some script enhancements. Why oh why do they
set such a bad example? I suppose it is a good example of Google Closure
library in action.

 

[David Mark]

I am experiencing a lot of problems using google.com search results,
GMail, and google groups today. I am using Firefox 3.6.3 with all
javascript enabled.

They all throw errors periodically for me, no matter what browser I use
(though the main site is the rarest offender). GG always barfs in Opera
10.5. I suppose if I go back one version at a time, I might hit the one
used by the developers (and therefore have some shot of the page
working). That's what observational programming does for you (software
as time capsule).

Tonight I am getting errors that are numbers:

".206"
".206"
".104"

Indeed it in the source, I see:

| throw new Error(".104");

LOL. That looks like Googledygook.

The layout for... wait. I am getting the OLD layout now. Haha, yay they
finally fixed it. JUST NOW, as I type this message.

They are watching us all.

Apparently somebody totally screwed up and broke Google.com search
results. Took em all day but they finally fixed it, but I swear, all of
today, the layout for the search results page showed the google "sprite"
image overlapping the search results, making it very hard to read the
first two results.

Too bad I did not get a screen shot of that.

Why? Everyone already knows their developers are incompetent (except
their developers of course). The perverse thing is that many other
firms use that fact as an excuse to be incompetent themselves (good
enough for Google!) They forget that they don't have Google's money
(which can minimize a lot of major problems).

It is amazing and pitiful at the same time. Google is a major tech
company, Firefox is a great browser, the page should be really simple to
make, just HTML, CSS, and some script enhancements. Why oh why do they
set such a bad example? I suppose it is a good example of Google Closure
library in action.

Probably. That dog don't hunt.

 

[Gregor Kofler]

Am 2010-05-07 09:57, Garrett Smith meinte:

[Google web page]

It is amazing and pitiful at the same time. Google is a major tech
company, Firefox is a great browser, the page should be really simple to
make, just HTML, CSS, and some script enhancements. Why oh why do they
set such a bad example? I suppose it is a good example of Google Closure
library in action.

It "looks" ok (now), but the validator still points out 121 errors and
38 warnings (on the super-simple start page, of course). Pathetic.

Gregor

 

[Ivan S]

I am experiencing a lot of problems using google.com search results,
GMail, and google groups today. I am using Firefox 3.6.3 with all
javascript enabled.

I've noticed that GMail throws (I guess ajax related) errors in FF
after some time.

 

[Garrett Smith]

I am experiencing a lot of problems using google.com search results,
GMail, and google groups today. I am using Firefox 3.6.3 with all
javascript enabled. [...]

Tonight I am getting errors that are numbers:

".206"
".206"
".104"

Indeed it in the source, I see:

| throw new Error(".104");

LOL. That looks like Googledygook.

They probably have "error codes" table somewhere.

More:

| try{}catch(u){}

and

| <ol onmouseover="return true"

[...]

Try Firefox plugin "Javascript Deobfuscator" to see more.
Now I have the new layout again; I see the issue.

Screenshot:
<http://dhtmlkitchen.com/img/blog/google.com.jpg>

Notice how the google sprite is displayed and overlaps the search result.

Am I the only one seeing this? FF 3.6.3 on Windows. I saw google.com
looking ok on another Firefox 3.5 on Mac.

NoScript is allowing all scripts there, too (otherwise a notice would be
displayed such as "Scripts Partially Allowed..." or "Scripts Currently
Forbidden".

Regardless, the sprite problem should not be a js issue. CSS Sprites are
created using one image and setting the css background-position,
normally in the stylesheet.

Why? Everyone already knows their developers are incompetent (except

Many, if not most non-developers tend to disagree.

their developers of course). The perverse thing is that many other
firms use that fact as an excuse to be incompetent themselves (good
enough for Google!) They forget that they don't have Google's money
(which can minimize a lot of major problems).

When I have made arguments about the importance of HTML validity, how it
causes javascript to work differently, how its use is expecting
error-correction, they have, on occasion, been downplayed with
justifications like:

"Who validates?" - "this is working fine" - "Look at any major site.
Even google.com doesn't validate. Do you really think it is that
important?"

 

[nick]

It "looks" ok (now), but the validator still points out 121 errors and
38 warnings (on the super-simple start page, of course). Pathetic.

What I find amusing is looking at Google Groups in Google Chrome with
the console up. Lots of DOM errors there.

 

[David Mark]

I am experiencing a lot of problems using google.com search results,
GMail, and google groups today. I am using Firefox 3.6.3 with all
javascript enabled. [...]

Tonight I am getting errors that are numbers:

".206"
".206"
".104"

Indeed it in the source, I see:

| throw new Error(".104");

LOL. That looks like Googledygook.

They probably have "error codes" table somewhere.

Yes, but why throw them at end-users? Looks like over-engineering to me
(i.e. throws outside of try-catch are usually pulled from production code).

More:

| try{}catch(u){}

Nothing I see out of their scripts surprises me. They often read like
random nonsense.

and

| <ol onmouseover="return true"

Or their markup.

[...]

Try Firefox plugin "Javascript Deobfuscator" to see more.
Now I have the new layout again; I see the issue.

Screenshot:
<http://dhtmlkitchen.com/img/blog/google.com.jpg>

I guess they don't test FF3.6. Odd choice for developers who clearly
program by feel (requiring feedback to know if they are doing right or
wrong).

Notice how the google sprite is displayed and overlaps the search result.

Yes. Clearly their CSS is broken somewhere. They should really sign up
for my support service (I'd ferret out the busted rule in thirty
seconds). But I guess whatever they have in place is "good enough" for
them.

Am I the only one seeing this? FF 3.6.3 on Windows. I saw google.com
looking ok on another Firefox 3.5 on Mac.

Hang on, let me fire it up. I rarely use it for anything other than
testing as it is a dog compared to Opera and Chrome.

No. It looks okay here. Their auto-complete is a piece of junk though.
Clicking elsewhere in the document did not close it (had to use the Esc
key). And how stupid is it to hide 80% of the page until the search box
is focused? The first time I saw that, I waited patiently for the rest
of the document to load. And waited, and waited... Finally I realized
they the effect was intentional. I guess they just wanted an excuse to
use that "modern" fade effect.

NoScript is allowing all scripts there, too (otherwise a notice would be
displayed such as "Scripts Partially Allowed..." or "Scripts Currently
Forbidden".

Can't imagine that scripts would be the culprit; but then, it is Google
we're talking about. If I were interested, I'd try disabling that plug-in.

Regardless, the sprite problem should not be a js issue. CSS Sprites are
created using one image and setting the css background-position,
normally in the stylesheet.


Many, if not most non-developers tend to disagree.

And on what basis could a non-developer judge the competence of a
developer. But I know that many do (e.g. "good enough for Google" excuses).

When I have made arguments about the importance of HTML validity, how it
causes javascript to work differently, how its use is expecting
error-correction, they have, on occasion, been downplayed with
justifications like:

"Who validates?" - "this is working fine" - "Look at any major site.
Even google.com doesn't validate. Do you really think it is that
important?"

Exactly. The answers are:-

1. Developers who wish to eliminate unneeded variables from an already
complex equation.

2. Empirical evidence based on peering at browsers on your desktop
should not be considered proof that something is "working fine".

3. They have no idea if Google validates or not. Invalid HTML may
simply indicate that they gave up on trying to make it valid (I've seen
that lots of times). Many Web developers are simply not qualified to
interpret the validation errors, which tend to cascade (e.g. one misstep
causes fifty errors). They get overwhelmed and don't realize that if
they could just fix the one root problem, the other forty-nine errors
would vanish.

It is odd that Google, with all of their money, can't seem to find good
help in their primary industry. Where are they based out of?
California? There's got to be at least a few out there.

 

[David Mark]

David Mark wrote:
Why? Everyone already knows [Google's] developers are incompetent
Many, if not most non-developers tend to disagree.

And on what basis could a non-developer judge the competence of a
developer.

On what basis can a non-musician judge the competence of a musician?

On what basis can a non-president judge the competence of a president?

On what basis can a non-designer judge the competence of a designer?

Obviously we can judge the competence of those outside our own field,
and rightly so if we can view the results of their work.

It's mot the same. The non-developers don't know anything but what they
see in their installed browsers (and what do they compare as virtually
every site on the Web is incompetently slapped together). Now, give
them a wide variety of browsers/modes/configurations to test, enable
error reporting so they can see the failings and perhaps they could
judge.

 

[Scott Sauyet]

Why?  Everyone already knows [Google's] developers are incompetent

Many, if not most non-developers tend to disagree.

And on what basis could a non-developer judge the competence of a
developer.

On what basis can a non-musician judge the competence of a musician?

On what basis can a non-president judge the competence of a president?

On what basis can a non-designer judge the competence of a designer?

Obviously we can judge the competence of those outside our own field,
and rightly so if we can view the results of their work.

-- Scott

 

[Scott Sauyet]

Garrett Smith wrote:
David Mark wrote:
Why?  Everyone already knows [Google's] developers are incompetent
Many, if not most non-developers tend to disagree.
And on what basis could a non-developer judge the competence of a
developer.

On what basis can a non-musician judge the competence of a musician?

As a non-musician, a judgement that one likes the music of one person
over another doesn't automatically qualify you as a judge or music.

It doesn't take a professional, though to determine that I'm a
terrible singer. Just listen to me in the shower, and you'll know for
sure. No expert consultation needed.

That you imply that the "man in the street" can judge the head of a
state even though that "man in the street" may have no real
understanding of the machinations of political opposition parties, the
media, the current economic climate... is ludicrous.

And to suggest that the only ones competent to judge the abilities of
a head of state are other heads of state is even more ludicrous, not
to mention extremely anti-democratic.

That it seems many people slavishly follow whatever the current trend
might be is indicative of a lack of understanding of design and hence to
know good design when they encounter it.

Are you a professional designer, then? Or on what basis are you
making that claim?

Your personal opinion may or may *not* matter.

No one's opinion of my rendition of "Solsbury Hill" or "If I Were a
Rich Man" is likely to matter. But if I were to try to promote it as
professional work, it would not take a Peter Gabriel or a Topol to
dismiss it. I'm sure you could easily determine that it's not
professional quality, unless you're entirely tone-deaf.

A surgeon may operate on someone yet that someone dies. To the family
the surgeon is incompetent. To the medical board it might be discovered
that some hitherto unknown medical condition caused it (the surgeon
could not reasonable have been expected to know).

So then it's only the point of view of the medical board that matters?

For me, I prefer to get opinions from those skilled in the particular field.

And exactly how are you going to determine who these skilled
practitioners are if you're not competent to judge the field? It
seems to me that you're caught in an endless loop. And hence I judge
that you must not be a skilled developer.

-- Scott

 

[David Mark]

Scott Sauyet wrote:

[...]

And exactly how are you going to determine who these skilled
practitioners are if you're not competent to judge the field? It
seems to me that you're caught in an endless loop. And hence I judge
that you must not be a skilled developer.

In the context of this industry, this is all silliness. For example,
there are ten gazillion possible configurations for IE, multiplied by
two layout modes, several "document mode" and "browser mode"
combinations (in 8) and at least three commonly used versions (not to
mention a fourth on the way). Furthermore, by default, exceptions are
not presented to the user in a noticeable way. And that's just _one_
major browser.

So if Joe Browser glances at Google's home page and investigates a few
features (which may appear to work, regardless of thrown exceptions), it
hardly puts them in a position to comment on the competence of Google's
front-end developers.

On the other hand, for a typical Google page, an experienced developer
can spot myriad, obvious gaffes within ten seconds, which clearly
indicates incompetence and/or thoughtlessness on the part of the
developers. They don't even need to waste time peering at the results
in a browser (knowing the results would be inconclusive at best).

So who would you ask?

 

[Scott Sauyet]

I quite like your shower version of My Way yesterday. Would have loved
to hear the end, but I had to split when you called the cops.

Oh, that was you? You really should have heard the finale. I
transposed it into the key of M-sharp; it was a thing of beauty!

-- Scott

 

[Scott Sauyet]

On 10/05/2010 12:15 PM, Scott Sauyet wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
Why?  Everyone already knows [Google's] developers are incompetent
Many, if not most non-developers tend to disagree.
And on what basis could a non-developer judge the competence of a
developer.
On what basis can a non-designer judge the competence of a designer?
That it seems many people slavishly follow whatever the current trend
might be is indicative of a lack of understanding of design and hence to
know good design when they encounter it.

Are you a professional designer, then?  Or on what basis are you
making that claim?

It seems that you're claiming that I need to competent in an area to
make a judgement.

It seems that you've forgotten which side of the argument you're
trying to defend.

 

[Scott Sauyet]

In the context of this industry, this is all silliness.  For example,
there are ten gazillion possible configurations for IE,

Actually, latest research shows 11.64 gazillion.

multiplied by
two layout modes, several "document mode" and "browser mode"
combinations (in 8) and at least three commonly used versions (not to
mention a fourth on the way).  Furthermore, by default, exceptions are
not presented to the user in a noticeable way.  And that's just _one_
major browser.

So if Joe Browser glances at Google's home page and investigates a few
features (which may appear to work, regardless of thrown exceptions), it
hardly puts them in a position to comment on the competence of Google's
front-end developers.

I guess that's where I disagree. It's Joe Browser that the
applications are written *for*. If they work to his expectations,
he's impressed. I might look at the code and shudder about its poor
maintainability, scalability, or performance. You might run screaming
at it's browser sniffing hacks or its inability to execute properly on
a certain old browser in a certain OS. Others will have their own,
possibly well-founded, objections. But none of that will take away
from the fact that Google delivered to Joe Browser what he wanted.
He's likely to look to Google for cues as to what's important or not
in code. From his perspective, Google has amazing developers.

And in fact, I think that Google has risen to its current heights
because of its competence. They're slowing down, and they're putting
out more junk than they used to. But they've gotten a lot right over
the years.

On the other hand, for a typical Google page, an experienced developer
can spot myriad, obvious gaffes within ten seconds, which clearly
indicates incompetence and/or thoughtlessness on the part of the
developers.  They don't even need to waste time peering at the results
in a browser (knowing the results would be inconclusive at best).

But when do those gaffes rise to the level of importance that Joe
Browser will be bothered by them?

I'm not exactly disagreeing with you, but I think that the perspective
of developers is not nearly as important as that of the end-users.
All developers know that the technical issues can eventually cause
horrible problems for users, but in the meantime, do you think Joe
Browser is going to care more about your technical critique or about
how Aunt Fanny finds this web thingy really easy to use now that she's
found Google's Widget 752?

So who would you ask?

In the end, the people paying the bills. And I'm afraid that the Joe
Browsers of the world are much more strongly represented among those
people than are the Richard Cornfords.

 

[David Mark]

Actually, latest research shows 11.64 gazillion.


I guess that's where I disagree. It's Joe Browser that the
applications are written *for*.

But you would need to poll ten million Joe Browsers to get any sort of
usable results.

If they work to his expectations,
he's impressed.

But he can't see what the next guy is going through. I use Google sites
occasionally and they invariably do things that indicate incompetence.

I might look at the code and shudder about its poor
maintainability, scalability, or performance. You might run screaming
at it's browser sniffing hacks or its inability to execute properly on
a certain old browser in a certain OS.

That latter point indicates they won't likely survive the new browsers
either. That's the point. And trying to constantly rewrite code that
is bad to begin with is not a recipe for success.

Others will have their own,
possibly well-founded, objections. But none of that will take away
from the fact that Google delivered to Joe Browser what he wanted.

BS. What if Joe Browser is blind, spastic, disables scripting, etc.,
etc. Only superficial observations could be in Google's favor (which is
all you will get out of an isolated Joe Browser). And he doesn't know
how much better it could have been either, likely forgiving time-wasting
errors as "one of those computer things".

He's likely to look to Google for cues as to what's important or not
in code. From his perspective, Google has amazing developers.

And that is a skewed perspective. Everything is relative and relatively
speaking, Google has _horrible_ front-end developers.

And in fact, I think that Google has risen to its current heights
because of its competence.

No, it was because of the millions of dollars of investor money; right
place, right time, right pitch, etc. They proceeded to do virtually
everything wrong, which didn't help; but they started with so much
momentum that it couldn't derail them either.

They're slowing down, and they're putting
out more junk than they used to. But they've gotten a lot right over
the years.

Not on the front-end they haven't. They are a poster child for futility
when it comes to markup, scripting, etc.

But when do those gaffes rise to the level of importance that Joe
Browser will be bothered by them?

I assume that's rhetorical (and I've already addressed it).

I'm not exactly disagreeing with you, but I think that the perspective
of developers is not nearly as important as that of the end-users.

From their perspective, we're all like totally awesome developers, dude.
How is that relevant for judging relative competence?

All developers know that the technical issues can eventually cause
horrible problems for users, but in the meantime, do you think Joe
Browser is going to care more about your technical critique or about
how Aunt Fanny finds this web thingy really easy to use now that she's
found Google's Widget 752?

The actual searching has nothing much to do with their execrable
front-end code. Their back-end developers may well be wizards, but they
are constantly undercut by the inept front-end. In other words, if they
could just get the two halves to the same level of competence, there'd
be no stopping them...

In the end, the people paying the bills. And I'm afraid that the Joe
Browsers of the world are much more strongly represented among those
people than are the Richard Cornfords.

You would ask the man on the street to judge the relative competence of
Web developers? It doesn't make sense.

 

[Scott Sauyet]

You would ask the man on the street to judge the relative competence of
Web developers?  It doesn't make sense.

No, I would ask the users of their products. It's their views that
are probably the most relevant. As I said, I personally might
disagree with them on technical grounds, but if you think technical
arguments win most decisions in software development, you're living in
a very different world than I.

 

[David Mark]

No, I would ask the users of their products. It's their views that
are probably the most relevant.

No. You switched arguments. We are talking about judging the
_competence_ of developers, which is not done in user focus groups.

As I said, I personally might
disagree with them on technical grounds, but if you think technical
arguments win most decisions in software development, you're living in
a very different world than I.

Not the "real world" argument. Yes, software development is a
technical business. You may be confusing UI design with development.
The line may be blurry in some cases, but it is still there.

 

[Scott Sauyet]

No.  You switched arguments.  We are talking about judging the
_competence_ of developers, which is not done in user focus groups.

I've occasionally -- not too often, I'm glad to say -- been in the
position of managing other developers. What I realized eventually is
that technical expertise is, sadly, only a small part of what makes
for a successful member of a development team. For one-person shows,
technical prowess is essential, and even for large teams I won't hire
people without clearly demonstrated technical skills. But for these
larger projects, a hugely important skill is thinking like a user of
the product under development. That skill is in many ways more
important than the technical ability. I would rather clean up after
someone who's left a technical mess but pleases the users than try to
upgrade a wonderfully designed and beautifully implemented system that
fails to meet the users' expectations.

I'm in that boat right now. I'm finding code like this:

function splitString(aString, spliter) {
var temp = new Array();
temp = aString.split(spliter);
return temp;
}

// ...

domainID = splitString(ids, '|')[1];
serverID = splitString(ids, '|')[2];
portID = splitString(ids, '|')[3];
formatID = splitString(ids, '|')[4];

This is clearly nonsense, and was written by someone who missed a lot
of the fundamentals of Javascript. But the users are very happy with
the results. It does what they need. They don't notice the
performance issues, and don't care about the architectural or
implementation decisions.

 

[Garrett Smith]

No. You switched arguments. We are talking about judging the
_competence_ of developers, which is not done in user focus groups.

[...]

This is clearly nonsense, and was written by someone who missed a lot
of the fundamentals of Javascript. But the users are very happy with
the results. It does what they need. They don't notice the
performance issues, and don't care about the architectural or
implementation decisions.

That problem is very basic in nature and supported natively by
ECMAScript, as revealed in line two of the body of the function.

That basic problem is addressed by five lines of code, four of which are
clutter. That's 80% of clutter. Its easy to see what is going on, as you
point out.

The water wings are working. He's over his head but he's not going to be
succumbed by a riptide.

Consider a Scheduler for a CMS now. Not a basic problem at all. This is
a larger problem that will require a much broader and much deeper
understanding of several technologies -- not just javascript strings and
arrays -- but will involve the DOM, Events, HTML, CSS, and server
communication. A good solution will also need more sophisticated
abstractions and code organization strategies.

Good abstractions deal with the problems at a level that they can be
understood. Good javascript abstractions also address the additional
constraint of dynamic deployment environment. By that, I mean browsers,
configurations, screen sizes, cache sizes, CPU, forwards and backwards
compatibility.

Had that developer been assigned to a complicated task like that, the
result would be at best, nipped in the bud at early stage, second to
that, a complete and total waste that got trashed, and at worst,
something that the manager tries to have everybody maintain when it
really needs rewriting. Unfortunately, that worst possible outcome is
the most common.

It could get nipped or transferred if the manager realizes that the
progress is not being made soon enough. If he has been working on the
problem for a month or so, stopping him at that point will be more
painful. The effort spent may be perceived as being greater than the
amount of effort required to get it done and so the manager says that:
"get it done!"

The five lines above, while senseless, would be nothing compared to a
wretched mess of unmaintainable two thousand lines. Shipped late, with
bugs.

It's all about the water.

 

[David Mark]

I've occasionally -- not too often, I'm glad to say -- been in the
position of managing other developers.

Join the club.

What I realized eventually is
that technical expertise is, sadly, only a small part of what makes
for a successful member of a development team.

It's a huge part of it in most cases. You just can't write good
software if you lack technical expertise. That's the problem with many
open source projects these days.

For one-person shows,
technical prowess is essential, and even for large teams I won't hire
people without clearly demonstrated technical skills.

I don't follow. What sort of programming team would be appropriate for
non-technical people (or people with poor technical skills).

But for these
larger projects, a hugely important skill is thinking like a user of
the product under development.

No kidding. UI design has been a specialty of mine for almost 20 years.

That skill is in many ways more
important than the technical ability.

It depends on your role. Designing and programming are two different
activities.

I would rather clean up after
someone who's left a technical mess but pleases the users than try to
upgrade a wonderfully designed and beautifully implemented system that
fails to meet the users' expectations.

Again, you seem to have a blurry picture of how software is created.

I'm in that boat right now. I'm finding code like this:

function splitString(aString, spliter) {
var temp = new Array();
temp = aString.split(spliter);
return temp;
}

// ...

domainID = splitString(ids, '|')[1];
serverID = splitString(ids, '|')[2];
portID = splitString(ids, '|')[3];
formatID = splitString(ids, '|')[4];

Fire whomever wrote that. Or, if they are a whiz at design, put them on
design. But don't let them write code.

This is clearly nonsense, and was written by someone who missed a lot
of the fundamentals of Javascript.

To say the least.

But the users are very happy with
the results. It does what they need. They don't notice the
performance issues, and don't care about the architectural or
implementation decisions.

So transfer them. But this has nothing to do with the original
discussion. In fact, you've proven my point. Users can't judge
developer competence. They can express a preference for a UI design,
but that has nothing to do with develop competence (and everything to do
with designer competence).