Bug 4788 – REGRESSION: Links inside Gmail don't respond to clicks

• Component: Layout and Rendering
• Status: CLOSED FIXED

[Jorge Salvador Caffarena]

Any link once logged in Gmail won't work, like trying to read a message, select all the "Unread" messages 
and similar.

Bug 4806 looks like it might be related to this bug.

[Mark Rowe (bdash)]

Confirmed with ToT WebKit from today.  A build from roughly a week ago does not exhibit the problem.  
Moving to P1 as it breaks a high-profile site.

Bug 4822 looks like it might be related to this bug.

Rolling out the patch for bug 4573 fixes this.

[Darin Adler]

We're pretty sure that we broke this by changing our event.button. Dave wants to ask Google to change 
their site and leave our code as is, which makes sense.

[Darin Adler]

I'd like to see this fixed one way or another soon. People want to use their nightly builds with GMail! 
Maybe we should temporarily back out the button fix until we can get Google to revise their site?

[Geoffrey Garen]

*** Bug 4998 has been marked as a duplicate of this bug. ***

[David Sternlight]

It's taking a really long time to fix this high-priority bug, which I suspect is causing many users attracted 
by recent publicity to try Webkit to drop out.

[Dave Hyatt]

The issue here is that the bug is effectively in the GMail code, which is making explicit assumptions about 
how event.button is supposed to work in Safari.  Now that we have changed the behavior to match the 
DOM specification (and Firefox), GMail's code no longer handles the values we return for event.button 
correctly.

[David Sternlight]

Firefox seems to work fine with gmail--both the current 1.07 and the 1.4 beta 1

[Dave Hyatt]

Correct.  Gmail user sniffs and goes down a different code path for Safari.  With these newer WebKit 
builds, their user agent code needs to treat us like Firefox instead.  That's the issue.

[Justin Sippel]

The problem with GMail changing their code is that out of all the people using
Safari, very few are using a development build of WebKit, built after this
button fix was landed. When you look at them as a total percentage of GMail
users, the number becomes vanishingly small. So I'm afraid there may not be much
value in GMail changing anything until such time as an updated version of
Safari/WebKit is released in Software Update. 

Side note, I had considered changing the UA to match Firefox as a potential
workaround, but it's not one of the choices available in the Debug menu.

[Dave Hyatt]

We are working with Google on this issue. Stay tuned.

[Shawn Smith]

Using Safari Stand would allow you to update the User Agent to Firefox.  Works pretty nicely except for the 
wrapping on the main window.

[Vicki Murley]

This is in Radar as <rdar://problems/4255698&4316066>

[David Sternlight]

It's not just cosmetic with the wrapping. If you use Stand, and go to the spam or trash pages, the lines on 
those pages permitting you to select all, so that you can, for example, select and then delete all spam, are 
missing. Normally they are at both the top and bottom of each such page.

[Darin Adler]

(In reply to comment #16)
> It's not just cosmetic with the wrapping. If you use Stand, and go to the spam or trash pages, the
> lines on those pages permitting you to select all, so that you can, for example, select and then delete
> all spam, are missing. Normally they are at both the top and bottom of each such page.

I don't understand this comment.

This bug is about clicks on links not working because the code checks the button number and we 
changed how button numbers are reported to match Gecko and the code assumes that we have our old 
quirk.

If you see other problems in GMail other than clicks not working, then you should file a separate bug.

I don't think there's anything above that claims this is a "cosmetic" bug nor anything that mentions 
wrapping, so I'm confused.

[David Sternlight]

My most recent comment was a response to Shawn Smith's statement that:
"Using Safari Stand would allow you to update the User Agent to Firefox.  Works pretty nicely except for 
the wrapping on the main window."

I didn't want anyone to think Smith's workaround completely solved the problem with gmail and this 
bug, since it seems not to give access to the "Select: All, None, Read, Unread, Starred, Unstarred" line at 
the top and bottom of each of gmail's label pages and thus leaves no way to select all spam (for 
example) and then delete it. You have to click on each spam message individually.

Note that the "Select: All, None, Read, Unread, Starred, Unstarred" appears normally with Safari. But with 
webkit and  the Safari Stand workaround, it is not available, unless there's some form for the browser 
masquerade entry in Stand I don't know about.

Gmail is working again. Perhaps something changed on their side?

[Daniel Udey]

As of Saturday, Nov 26th's ToT build, GMail links appear to be working. I don't want to seem hasty (Google 
might have changed their code), but the problem appears to have been solved. Could someone with an 
older build of ToT confirm whether the site still breaks in older builds? Either way, unless the problem re-
regresses, this bug seems done.

I just verified that Gmail now works with the Oct 1 build of WebKit too.

[Mark Rowe (bdash)]

I've just verified that the Gmail JavaScript now checks if the WebKit version is > 420 and acts accordingly.

[Vicki Murley]

Closing this bug.