Bug 22633 – [Gtk] Unavailability to access windows live hotmail

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: WebKitGTK

[yepi]

Access to windows live hotmail is imposible, the adress keeps redirecting infinitely without showing anything, the adress becomes like this:
http://by105w.bay105.mail.live.com/mail/TodayLight.aspx?n=1032699004&wa=wsignin1.0&n=131387298&n=1266646317&n=156362077&n=1846041760&n=362001215&n=1979351116&n=999241808&n=1055157504&n=1978210773&n=1251213796&n=41655746&n=1837549874&n=844015478&n=1794322225&n=693282867&n=46604488&n=185867109&n=397314179&n=1353752535&n=999899053&n=1042728931&n=479460387&n=1618411875&n=984353531&n=1635205281
Everytime more and more &n=xxxxxxxx continue to be added.
Terminal shows:
console message: http://gfx6.hotmail.com/mail/13.2.0242.1113/cmpt0.js @1: TypeError: Result of expression 'a.HTMLElement.prototype' [null] is not an object.

This reapeats many times, i believe everytime a &n=xxxxxxxx is added to the adress.

I'm using Xubuntu 8.10 and lastest nightly build.

[yepi]

Deactivating Javascript enables the page to load but cannot click access any mail by clicking its link, afeter loading the pages enabling javascript will bring to the same error

[Joachim Frieben]

I do see the same issue here on an x86_64 F10 system w/updates for the official package midori-0.0.21 which is built against WebKit-gtk r37790 but also for packages epiphany-2.24.1 and midori-0.1.11 built locally against the *latest* nightly build r39903.
It turns out that file ".xsession-errors" is filled with related entries for each load cycle reading

 "console message: http://gfx6.hotmail.com/mail/13.2.0260.1209/cmpt0.js @1: TypeError: Result of expression 'a.HTMLElement.prototype' [null] is not an object."

[Cynthia]

I can't open any mail in Hotmail. If I click on the mail to open it, it doesn't work..

[Joachim Frieben]

It still not possible to open individual mails in the inbox of my Hotmail account with webkitgtk-1.1.7.

[Joachim Frieben]

Hotmail buttons generally still do not work with current webkit; observer under Fedora 11 using
- midori-0.1.7-1.fc11.x86_64
- webkitgtk-1.1.10-1.fc11.x86_64
Any clues in which direction to investigate futher?

[Joachim Frieben]

For the current Fedora "rawhide" tree, there is some progress:

- webkitgtk-1.1.14-3.fc12.x86_64 / midori-0.1.10-1.fc12.x86_64 [SUCCESS]
- webkitgtk-1.1.14-3.fc12.x86_64 / epiphany-2.27.92-2.fc12.x86_64 [FAILURE]

Now, if success depends on the frontend, this might finally not be a webkitgtk
issue, might it?

[Jan Alonzo]

(In reply to comment #6)
> For the current Fedora "rawhide" tree, there is some progress:
> 
> - webkitgtk-1.1.14-3.fc12.x86_64 / midori-0.1.10-1.fc12.x86_64 [SUCCESS]
> - webkitgtk-1.1.14-3.fc12.x86_64 / epiphany-2.27.92-2.fc12.x86_64 [FAILURE]
> 
> Now, if success depends on the frontend, this might finally not be a webkitgtk
> issue, might it?

That's right. It would be better to raise this issue to the embedder instead. Can someone confirm that this is a UA issue?

[Joachim Frieben]

Issue solved for Fedora 11, too, now:
- webkitgtk-1.1.10-1.fc11.x86_64 / midori-0.1.10-1.fc11.x86_64

[Jan Alonzo]

(In reply to comment #8)
> Issue solved for Fedora 11, too, now:
> - webkitgtk-1.1.10-1.fc11.x86_64 / midori-0.1.10-1.fc11.x86_64

Closing. Confirmed fix in 1.1.10. If this fails in epiphany, please file a bug in epiphany's bug tracker.

[Xan Lopez]

(In reply to comment #9)
> (In reply to comment #8)
> > Issue solved for Fedora 11, too, now:
> > - webkitgtk-1.1.10-1.fc11.x86_64 / midori-0.1.10-1.fc11.x86_64
> 
> Closing. Confirmed fix in 1.1.10. If this fails in epiphany, please file a bug
> in epiphany's bug tracker.

So...

- midori-0.1.7-1.fc11.x86_64
- webkitgtk-1.1.10-1.fc11.x86_64

This fails.

Issue solved for Fedora 11, too, now:
- webkitgtk-1.1.10-1.fc11.x86_64 / midori-0.1.10-1.fc11.x86_64

This works.

Since the webkit version is the same I guess it's obvious midori is doing some workaround on its own and that 1.1.10 didn't "fix" anything. Christian, what are you doing? Is it something that webkit should do itself and that you are just working around?

[Joachim Frieben]

I have traced back the issue with midori on Fedora 11, and it turns out that keeping webkitgtk-1.1.10 fixed, the watershed occurs between midori-0.1.4-2.fc11 and midori-0.1.5-1.fc11,

  midori-0.1.4-2.fc11  [FAILURE]
  ------------------------------
  midori-0.1.5-1.fc11  [SUCCESS]
  .
  .
  midori-0.1.10-1.fc11 [SUCCESS] .

I cannot tell why in comment #5 I had reported failure for midori-0.1.7. I can only speculate whether some underlying system library has been updated in the meantime leading to this shift. Anyway, for a current Fedora 11 system sporting webkitgtk-1.1.10, above observation applies. Using midori-0.1.4-2.fc11, it is possible to log in successfully, to navigate through the Hotmail directory tree, but clicking some message has no effect. Only "javascript:" appears in the footer of the browser window then.

[Christian Dywan]

I suspect this might be the user agent, earlier Midori versions could not change the user agent string that javascripts see. I suggest you change it in the Network preferences and see if it helps.

[Joachim Frieben]

Midori is not an issue anymore, now that even v 0.1.5 works as expected. What causes me more of a headache is that final epiphany 2.28.0 is still broken in this respect, and the it has a much bigger user base.

[Xan Lopez]

(In reply to comment #12)
> I suspect this might be the user agent, earlier Midori versions could not
> change the user agent string that javascripts see. I suggest you change it in
> the Network preferences and see if it helps.

So what are you using as UA? Could you reset it to WebKit's default and see if that makes Hotmail not work?