Bug 35830 - Unable to use Hotmail.com mail features, as clicking on links seems not to work
Summary: Unable to use Hotmail.com mail features, as clicking on links seems not to work
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other All
: P1 Major
Assignee: Simon Hausmann
URL:
Keywords: Gtk, Qt, QtTriaged
Depends on:
Blocks: 35784
  Show dependency treegraph
 
Reported: 2010-03-06 11:52 PST by pano_90
Modified: 2014-04-24 16:45 PDT (History)
11 users (show)

See Also:


Attachments
Patch (3.48 KB, patch)
2010-04-08 05:55 PDT, Simon Hausmann
gns: review+
laszlo.gombos: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description pano_90 2010-03-06 11:52:52 PST
When arriving to hotmail.com's page which lists your e-mails, nothing works,
clicking links doesn't do anything.
It does not work in rekonq, nor arora.

I created a test account on hotmail so that you don't have to :-P

Username:
weqtvy3@hotmail.com

Password:
123456

After logging in, you might see a page stating that you should upgrade your webbrowser. Simply ignore this and browse to the mails by clicking on Mail in the upper part of the website.
clicking on the mail does not work, the commands (on the lower part of the website "New, Delete, Junk …") do not work either.



Original bug report: https://bugs.kde.org/show_bug.cgi?id=228475


Thanks :-)
Comment 1 pano_90 2010-03-06 11:57:58 PST
Forgot to mention:

Tested here with Qt 4.6.1
Comment 2 Tor Arne Vestbø 2010-03-10 06:33:23 PST
Please follow the QtWebKit bug reporting guidelines when reporting bugs.

See http://trac.webkit.org/wiki/QtWebKitBugs

Specifically:

  - The 'QtWebKit' component should only be used for bugs/features in the
    public QtWebKit API layer, not to signify that the bug is specific to
    the Qt port of WebKit

      http://trac.webkit.org/wiki/QtWebKitBugs#Component

  - Add the keyword 'Qt' to signal that it's a Qt-related bug

      http://trac.webkit.org/wiki/QtWebKitBugs#Keywords
Comment 3 Jocelyn Turcotte 2010-03-11 05:45:56 PST
Reproduced in trunk with Qt 4.6.

We have to try fixing this for the next issue, depending on the work needed.
Comment 4 Jędrzej Nowacki 2010-03-18 08:50:21 PDT
Reproduced on Linux(32 bit Debian/testing):
- with trunk of the Qt and the WebKit using QtLauncher.
- with trunk of the WebKit using GtkLauncher.

I tried to debug it, but it is rather difficult with obscured JavaScript code from that page. If someone know how to debug this kind of bugs, please share your knowledge :-).
Comment 5 Kent Hansen 2010-04-06 07:32:53 PDT
(In reply to comment #4)
> I tried to debug it, but it is rather difficult with obscured JavaScript code
> from that page. If someone know how to debug this kind of bugs, please share
> your knowledge :-).

I used http://jsbeautifier.org to unminify the JS.
http://gfx6.hotmail.com/mail/15.1.3057.0331/i0a.mozilla.js seems to contain the relevant code, e.g. search for NewMessage / newMsg for code that should be triggered when clicking on the "New" item.
My idea for debugging is to patch the network handler to deliver the unminified versions of the scripts, so that we can get line numbers and set breakpoints in the Inspector. We can even insert debug statements in the unminified script... :-)
Comment 6 Simon Hausmann 2010-04-08 02:20:19 PDT
It appears that hotmail.com does not work with our default user agent string, which is

Mozilla/5.0 (%Platform%; %Security%; %Subplatform%; %Locale%) AppleWebKit/%WebKitVersion% (KHTML, like Gecko) %AppVersion Safari/%WebKitVersion%


However it works when inserting a Version/4.0 component, so that the resulting string is for example on Linux:

Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Version/4.0 QtLauncher/0.1  Safari/533.4


What do you guys think about adding the "arbitrary" Version/4.0 compoment?

Note that the order is significant: It only works if the Version component follows directly the AppleWebKit/... (KHTML...) part.
Comment 7 Yael 2010-04-08 05:17:35 PDT
(In reply to comment #6)

> What do you guys think about adding the "arbitrary" Version/4.0 compoment?
> 
> Note that the order is significant: It only works if the Version component
> follows directly the AppleWebKit/... (KHTML...) part.

A few years ago we updated webkit in S60, to the version of Safari 3.0. At the time, I did exactly the same thing in order to make hotmail.com work. (add version 3.0)
Comment 8 Kenneth Rohde Christiansen 2010-04-08 05:40:28 PDT
(In reply to comment #6)
> It appears that hotmail.com does not work with our default user agent string,
> which is
> 
> Mozilla/5.0 (%Platform%; %Security%; %Subplatform%; %Locale%)
> AppleWebKit/%WebKitVersion% (KHTML, like Gecko) %AppVersion
> Safari/%WebKitVersion%
> 
> 
> However it works when inserting a Version/4.0 component, so that the resulting
> string is for example on Linux:
> 
> Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.4 (KHTML, like Gecko)
> Version/4.0 QtLauncher/0.1  Safari/533.4
> 
> 
> What do you guys think about adding the "arbitrary" Version/4.0 compoment?
> 
> Note that the order is significant: It only works if the Version component
> follows directly the AppleWebKit/... (KHTML...) part.

Android adds it, and iPad adds Version/4.0.4. I think it would be fine for us to do that as well.
Comment 9 Kenneth Rohde Christiansen 2010-04-08 05:44:12 PDT
> Android adds it, and iPad adds Version/4.0.4. I think it would be fine for us
> to do that as well.

The full iPad string is:

Mozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

Funny to see that they kept "iPhone" in the string :-) On the iPhone it doesn't say "CPU iPhone OS 3_2 like Mac OS X" but "CPU OS 3_2 like Mac OS X"
Comment 10 Simon Hausmann 2010-04-08 05:55:49 PDT
Created attachment 52854 [details]
Patch
Comment 11 Kenneth Rohde Christiansen 2010-04-08 06:17:19 PDT
Comment on attachment 52854 [details]
Patch

Why not use 4.0.4 as the iPad?
Comment 12 Gustavo Noronha (kov) 2010-04-08 06:28:01 PDT
Comment on attachment 52854 [details]
Patch

Sounds good to me. rs=me on changing this to 4.0.4 if you feel the need, but I think we should be fine with the existing practice.
Comment 13 Simon Hausmann 2010-04-08 06:39:02 PDT
Comment on attachment 52854 [details]
Patch

Thanks for the review Gustavo. I'm holding off the commit queue to give some more time for feedback before landing.
Comment 14 Kenneth Rohde Christiansen 2010-04-08 06:41:19 PDT
(In reply to comment #13)
> (From update of attachment 52854 [details])
> Thanks for the review Gustavo. I'm holding off the commit queue to give some
> more time for feedback before landing.

I would still like to know the advantage of using 4.0 instead of 4.0.4 which seems to be the latest version uses. Does it work with 4.0.4?
Comment 15 Simon Hausmann 2010-04-08 07:08:32 PDT
(In reply to comment #14)
> (In reply to comment #13)
> > (From update of attachment 52854 [details] [details])
> > Thanks for the review Gustavo. I'm holding off the commit queue to give some
> > more time for feedback before landing.
> 
> I would still like to know the advantage of using 4.0 instead of 4.0.4 which
> seems to be the latest version uses. Does it work with 4.0.4?

I can confirm that it works with 4.0.4, but what's the advantage of a more specific number over a major one? :)
Comment 16 Kenneth Rohde Christiansen 2010-04-08 07:13:08 PDT
Isn't it considered a minimum required version, thus 4.0.4 right be required by some services where 4.0 would fail? I'm not sure, but there must be a reason it was chosen for iPhone and iPad.
Comment 17 Kent Hansen 2010-04-08 07:29:32 PDT
(In reply to comment #16)
> Isn't it considered a minimum required version, thus 4.0.4 right be required by
> some services where 4.0 would fail? I'm not sure, but there must be a reason it
> was chosen for iPhone and iPad.

4.0.4 is so oldschool; it's a "4.0.4 Not Found" waiting to happen. 4.1 works, as does 5.0. Might as well be future-proof (it should increase the time until this task must be reopened to bump the version again). :P
Comment 18 Kenneth Rohde Christiansen 2010-04-08 07:35:49 PDT
(In reply to comment #17)
> (In reply to comment #16)
> > Isn't it considered a minimum required version, thus 4.0.4 right be required by
> > some services where 4.0 would fail? I'm not sure, but there must be a reason it
> > was chosen for iPhone and iPad.
> 
> 4.0.4 is so oldschool; it's a "4.0.4 Not Found" waiting to happen. 4.1 works,
> as does 5.0. Might as well be future-proof (it should increase the time until
> this task must be reopened to bump the version again). :P

Then use 4.0.5 which is the latest Safari version. The 4.0.4 or higher might be required to use some newer service being made for the iPad.
Comment 19 Laszlo Gombos 2010-04-08 08:45:10 PDT
According to this content - http://www.useragentstring.com/pages/Chrome/ Chrome does not add the "Version" part to the UA header. Taking a closer look it seems like Chrome had this for one single version and than its gone again (see Chrome 2.0.156.0). I do not know if this info helps in any way to make this decision.

It would be good if we could only carry one cross-platform WebKit version around. With this patch it seems like we will have two version number (with the risk of the two being inconsistent).
Comment 20 Laszlo Gombos 2010-04-08 09:34:39 PDT
Just to be specific, I'm ok with the change but would be somehow better to pick up the number cleverly (if possible) than hard-coding it.

It would also be useful to track down the JavaScript which check for the version (instead of doing object/feature detection). If it is a JavaScript library that is used in many places would be worthwhile to fix the JavaScript library (as well).
Comment 21 Kenneth Rohde Christiansen 2010-04-08 09:38:41 PDT
kenne> aroben do you know if the Version/4.0.4 in the UA is the Safari version? or what does it represent?
<aroben> kenne: yes, that is the Safari version
Comment 22 Simon Hausmann 2010-04-26 08:40:24 PDT
(In reply to comment #19)
> According to this content - http://www.useragentstring.com/pages/Chrome/ Chrome
> does not add the "Version" part to the UA header. Taking a closer look it seems
> like Chrome had this for one single version and than its gone again (see Chrome
> 2.0.156.0). I do not know if this info helps in any way to make this decision.
> 
> It would be good if we could only carry one cross-platform WebKit version
> around. With this patch it seems like we will have two version number (with the
> risk of the two being inconsistent).

What's the other option?

We have to include this tag in order for the web site to function. The tag/version does not come from WebKit but from an external third-party product ;(

I guess the other option would be to pretend to be Chrome and not include a version...
Comment 23 Kenneth Rohde Christiansen 2010-04-26 10:09:52 PDT
Or make a quirk that returns a different UA for the site?
Comment 24 Kenneth Rohde Christiansen 2010-05-07 06:29:10 PDT
(In reply to comment #23)
> Or make a quirk that returns a different UA for the site?

We need to decide on this one.
Comment 25 Simon Hausmann 2010-05-12 06:14:02 PDT
We decided to try to solve this on the server side and otherwise land it as-is on May the 26th.
Comment 26 Laszlo Gombos 2010-05-16 13:55:50 PDT
Comment on attachment 52854 [details]
Patch

cq- until we conclude investigation on the server side.
Comment 27 Kenneth Rohde Christiansen 2010-05-22 12:25:43 PDT
(In reply to comment #26)
> (From update of attachment 52854 [details])
> cq- until we conclude investigation on the server side.

Any update on this Laszlo? We have almost waited long enough.
Comment 28 Laszlo Gombos 2010-05-22 18:05:02 PDT
This is not resolved yet but I got a very promising verbal promise that fix on the server side can be arrange and with that we were asked to not hack around this issue on the client/UA side. I suggest we close this bug without committing the patch.
Comment 29 Kenneth Rohde Christiansen 2010-05-22 18:44:52 PDT
Ok, let's close it then. Thanks for looking into this.
Comment 30 Darin Adler 2014-04-24 16:45:13 PDT
Moving all JavaScriptGlue bugs to JavaScriptCore. The JavaScriptGlue framework itself is long gone. And most of the more recent bugs put in this component were put there by people who thought this was for some other aspect of “JavaScript glue” and have nothing to do with the actual original reason for the existence of this component, which was an OS-X-only framework named JavaScriptGlue.