Bug 35830 – Unable to use Hotmail.com mail features, as clicking on links seems not to work

• Status: RESOLVED
• Resolution: WONTFIX
• Component: JavaScriptCore

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:
[e-mail]

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 :-)

Forgot to mention:

Tested here with Qt 4.6.1

[Tor Arne Vestbø]

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

[Jocelyn Turcotte]

Reproduced in trunk with Qt 4.6.

We have to try fixing this for the next issue, depending on the work needed.

[Jędrzej Nowacki]

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 :-).

[Kent Hansen]

(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... :-)

[Simon Hausmann]

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.

[Yael]

(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)

[Kenneth Rohde Christiansen]

(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.

[Kenneth Rohde Christiansen]

> 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"

[Simon Hausmann]

Created attachment 52854 [details]
Patch

[Kenneth Rohde Christiansen]

Comment on attachment 52854 [details]
Patch

Why not use 4.0.4 as the iPad?

[Gustavo Noronha (kov)]

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.

[Simon Hausmann]

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.

[Kenneth Rohde Christiansen]

(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?

[Simon Hausmann]

(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? :)

[Kenneth Rohde Christiansen]

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.

[Kent Hansen]

(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

[Kenneth Rohde Christiansen]

(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.

[Laszlo Gombos]

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).

[Laszlo Gombos]

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).

[Kenneth Rohde Christiansen]

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

[Simon Hausmann]

(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...

[Kenneth Rohde Christiansen]

Or make a quirk that returns a different UA for the site?

[Kenneth Rohde Christiansen]

(In reply to comment #23)
> Or make a quirk that returns a different UA for the site?

We need to decide on this one.

[Simon Hausmann]

We decided to try to solve this on the server side and otherwise land it as-is on May the 26th.

[Laszlo Gombos]

Comment on attachment 52854 [details]
Patch

cq- until we conclude investigation on the server side.

[Kenneth Rohde Christiansen]

(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.

[Laszlo Gombos]

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.

[Kenneth Rohde Christiansen]

Ok, let's close it then. Thanks for looking into this.

[Darin Adler]

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.