Bug 35830

Forgot to mention: Tested here with Qt 4.6.1

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

Reproduced in trunk with Qt 4.6. We have to try fixing this for the next issue, depending on the work needed.

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

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

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.

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

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

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

Created attachment 52854 [details] Patch

Comment on attachment 52854 [details] Patch Why not use 4.0.4 as the iPad?

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

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

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

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.

(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

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

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

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

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

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

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

(In reply to comment #23) > Or make a quirk that returns a different UA for the site? We need to decide on this one.

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

Comment on attachment 52854 [details] Patch cq- until we conclude investigation on the server side.

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

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.

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

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.