Bug 25826 – REGRESSION: In Gmail's Edit Link dialog, I can't type in the Link To: field (due to <input type=url> support)

• Component: DOM
• Status: RESOLVED FIXED

[Sam Weinig]

* SUMMARY
In Gmail's Edit Link dialog, I can't type in the Link To: field to create a link in message.

* STEPS TO REPRODUCE
1. Launch TOT and login into your gmail account
2. Click Compose Mail
3. In the message body, type hello and select this word
4. Click on Link icon. In the Gmail's Edit Link dialog that appears, the Link To : field has a focus ring but I can't type in it.


This regressed due to http://trac.webkit.org/changeset/43267.

[Sam Weinig]

<rdar://problem/6884742>

[Sam Weinig]

Created attachment 30396 [details]
patch

[Alexey Proskuryakov]

What is special about <input type=url> at gmail that prevents typing? Will the problem occur on other sites using this input type?

[Beth Dakin]

Comment on attachment 30396 [details]
patch

r=me

[Sam Weinig]

(In reply to comment #3)
> What is special about <input type=url> at gmail that prevents typing? Will the
> problem occur on other sites using this input type?
> 

They are expecting input.type for <input type=url> to return the string "text".  It will only break other sites if they are expecting that as well, but there is no evidence of this.  

[Sam Weinig]

Fixed in r43779.

[David Kilzer (:ddkilzer)]

Do international Google Mail sites use different domain names?

[David Kilzer (:ddkilzer)]

<rdar://problem/6884742>

[Erik Arvidsson]

This is really ugly work around and it will not work very well. Tons of other domains uses the same code. Gmail in UK and Germany uses another domain. Google Docs also uses this code and I believe Blogger and other high traffic sites as well.

I'll try to get this fixed ASAP on our side. It makes no sense to have this work around in WebKit and it will cause more obscure bugs when Gmail wants input.type to return 'url' in the future.

[Dimitri Glazkov (Google)]

Chromium build fix landed as http://trac.webkit.org/changeset/43784.

[Erik Arvidsson]

We have now fixed the code in Gmail. It will take some time for this to go live since it isn't really a high priority bug on our side since the bug only affects beta versions of Chrome and Safari.

Can you please roll back this hack now?

[Eric Seidel (no email)]

I would agree that this patch won't fix Gmail very well.  There are lots of domains which use this code, googlemail.com being the most obvious one (and as Arv mentions, other products too).

I would recommend rolling this out before shipping Safari 4 or Chrome 2.  Google should be responsible for fixing this from their side IMO.

I'm going to re-open the bug, but feel free to close again, and I'm happy to file a separate bug about rollout.

[Mark Rowe (bdash)]

If we need to make the workaround more robust, we should do that.  I don’t see how we can revert the workaround until Gmail is fixed.  If Google folks are unhappy about the presence of the workaround then they should focus on getting the Gmail fix deployed.

[Sam Weinig]

I would rather not roll out the fix entirely until the fix is deployed on googles end.  We can however make it more robust, perhaps returning "text' for <input type="url"> regardless of origin in the js bindings (I don't want to infect ObjC binding with this quirk).  If you are you able to provide a timeline for when the fix will be out it would be helpful, but I understand if this is not possible. 

For what it is worth, googlemail.com seems to re-direct to mail.google.com for me and I can not reproduce this bug on docs.google.com.

[Eric Seidel (no email)]

I got more information from Julie Parent.  I have "seen the light" and agree that a temporary workaround like this is a good thing.

1.  The bug has existed in the shared JavaScript rich-text editing library Google uses (TrogEdit) since 2006. (Ironically WebKit hackers Ojan & Julie are primarily responsible for this library.)
2.  Trivia: the faulty code was originally added for Opera, which was the only one which supported type="url" at that time.
3.  Not all products use TrogEdit's link-insertion dialog.  The Word processor @ docs.google.com is one example of an application with a custom link-insert dialog (hence why Sam couldn't repro there).
4.  Julie wouldn't be able to list all the domains which use TrogEdit.  I'm not sure anyone could easily.  It's used by *lots* of apps @ google.  Gmail is the highest-profile I know of.
5.  The fix has been checked into TrogEdit.  Some apps may have already released the fix.  Some end-of-life apps will probably never do so (like pages.google.com).  I don't have a timeline for Gmail, but Arv (Erik Arvidsson) might.

I guess my personal opinion would be we should leave this on trunk until Safari 4 and Chrome 2 go out the door, and then roll it out again.

The check could be expanded to ".google.com" but even that might not be complete.  Making this quirk universal might be the best option.  Julie might be able to give some advice here (by thinking of any other high-profile google domains using TrogEdit).

[Eric Seidel (no email)]

Oh yeah. I believe anyone using Google Apps for your domain can run the app under any domain they want.  So anyone who is using Gmail for your domain will be broken too.  I don't know much about Google Apps for your domain usage, but I wouldn't be surprised if some rather large schools are using it.

Someone who knows more about Google Apps for your domain should confirm this suspicion! (Really credit is due to Mike Lambert for bringing this up.)

Result: we would need to enable this fix for all domains to fix Google Apps for Your Domain usage of Gmail (and possibly other Apps which depend on TrogEdit's insert link dialog).

[Mark Rowe (bdash)]

(In reply to comment #16)
> Oh yeah. I believe anyone using Google Apps for your domain can run the app
> under any domain they want.  So anyone who is using Gmail for your domain will
> be broken too.  I don't know much about Google Apps for your domain usage, but
> I wouldn't be surprised if some rather large schools are using it.
> 
> Someone who knows more about Google Apps for your domain should confirm this
> suspicion! (Really credit is due to Mike Lambert for bringing this up.)
> 
> Result: we would need to enable this fix for all domains to fix Google Apps for
> Your Domain usage of Gmail (and possibly other Apps which depend on TrogEdit's
> insert link dialog).

I use Google Apps for my domain and it too redirects to mail.google.com for Mail.  Is there any real evidence that this affects anything but mail.google.com?   So far there's been an awful lot of speculation and little evidence to demonstrate that the workaround is insufficient.

[Eric Seidel (no email)]

I'm done speculating.  Do what you want.

I failed to reproduce this bug on docs.google.com (all 3 products), pages.google.com, and sites.google.com.

[Sam Weinig]

:( Well, the best solution is (I think at least) to get the fix out the door ASAP on the Google side.  For the time being, I am going to leave the fix in as it is (behind the site specific quirk flag so that Google engineers can turn it off via the Develop menu) and remove it as soon as the fix is released.  Please re-open if you have a better solution that can address more people, more effectively.

[Julie Parent]

Other external consumer products this bug is visible in:
* Google Notebook (notebook.google.com)
* Google Groups (groups.google.com, Pages feature)
* Blogger (draft.blogger.com only)

These should have it, but I haven't verified since I don't speak these languages and have no idea how to get to the link dialog ...
* http://wenda.tianya.cn/wenda/
* http://otvety.google.ru/otvety/

There are likely a few other smaller products and Google internal products that will have this bug too.

The fix on the Google side was to the base library and so it will get into these products when they do their next releases, but Google Notebook is a cancelled product and is unlikely to do another push to fix this bug.

[Sam Weinig]

(In reply to comment #20)
> Other external consumer products this bug is visible in:
> * Google Notebook (notebook.google.com)
> * Google Groups (groups.google.com, Pages feature)
> * Blogger (draft.blogger.com only)
> 
> These should have it, but I haven't verified since I don't speak these
> languages and have no idea how to get to the link dialog ...
> * http://wenda.tianya.cn/wenda/
> * http://otvety.google.ru/otvety/
> 
> There are likely a few other smaller products and Google internal products that
> will have this bug too.
> 
> The fix on the Google side was to the base library and so it will get into
> these products when they do their next releases, but Google Notebook is a
> cancelled product and is unlikely to do another push to fix this bug.

Ok, cool.  With this information, I think we should extend the quirk to all urls until the fix is rolled out.  I will handle that.

[Julie Parent]

I've contacted all of the teams using this link dialog and informed them of the situation.  I'll update this bug once I have confirmed from them when they'll be rolling out fixes.

[Eric Seidel (no email)]

More data in case it's useful:
Me: "Are [Google Apps for Your Domain] Apps (like gmail) ever run under domains other than Google.com?"
Derek [Tech Lead for GA4YD]: "Yes, they are.  Some of our ISP partners for instance have urls like mail.isp.com, calendar.isp.com"

I don't know what those ISP partners are, or how large they are.  I can ask Derek for that information if needed.

[Julie Parent]

Google Groups should have a fix live on June 3.
Blogger should have a fix live on May 27.
Gmail should have a fix live next week.

[Julie Parent]

And Notebook will have the fix live by the end of this week.

So, all Google properties that are known to have this bug will have fixes pushed by June 3 at the latest.

[Eric Seidel (no email)]

Comment on attachment 30396 [details]
patch

clearing flag to remove from commit queue.

[Ahmad Saleem]

I see these two patches landing:

https://github.com/WebKit/WebKit/commit/1c64d7c219ada2d4f77c5504c24f6e9e6b6631d4

https://github.com/WebKit/WebKit/commit/114cfe9768dc31ab0a4b26c245dd5e9db5ccbefb

But not backing out. Consider this bug as fixed at the time. I am going to mark this as "RESOLVED FIXED" and I am sure the code has since evolved a lot to modify the same code block several times and even fixing the issue at root level.

Please reopen, if you believe there is more to do here. Thanks!