Project

General

Profile

Actions
Copy link

Bug #4492

open

WAbstractArea might fire beforeunload event in some versions of Internet Explorer

Added by Florian Ransmayr over 8 years ago. Updated over 8 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Koen Deforche
Target version:
3.3.5
Start date:
09/22/2015
Due date:
% Done:

0%

Estimated time:

Description

In a project I created some interactive polygon areas on an background image. The interactivity is using the mousewentdown and mousewentup events on that areas. Recently I had the problem the on each click of such an area the Internet Explorer version 10.x asked me to confirm leaving the page. I used WApplication::setConfirmCloseMessage("..") to create a message if the user tries to navigate away. So there seems to be something wrong for this combination in combination with the internet explorer.

I found the following link describing the problem and a possible solution: http://stackoverflow.com/questions/10548614/anchor-javascriptvoid0-causing-window-onbeforeunload-to-fire-on-ie

After that I tried to fix it in C source with a WAbstractArea::clicked().preventDefaultAction() that worked for me quit good. At the moment I have one problem left. In my application it is possible to drag&drop the areas around. If I now drag&drop the areas around I still got the beforeunload event. It seems that the preventDefaultAction() is useless in this special case.

Attached is a modified hello example that demonstrates the behavior of the interactive areas in combination with the beforeunload event.

Maybe you can give me some tips or improve the code generation regarding this.

Thanks a lot

Florian

Files

hello.zip (33.7 KB) hello.zip Florian Ransmayr, 09/22/2015 03:02 PM
Actions
Copy link
 #1

Updated by Florian Ransmayr over 8 years ago

Uups forgot to mention that I used the version 3.3.5 RC1 of Wt.

Actions
Copy link
 #2

Updated by Koen Deforche over 8 years ago

  • Status changed from New to InProgress
  • Assignee set to Koen Deforche
  • Target version set to 3.3.5
Actions
Copy link
 #3

Updated by Florian Ransmayr over 8 years ago

Hey koen,

any update on this issue? Did you manage to reproduce this issue? Do you need further information/specification?

Thanks

Sulando

Actions
Copy link
 #4

Updated by Koen Deforche over 8 years ago

  • Status changed from InProgress to Feedback

Hey,

I managed to reproduce this (with IE8 but not with more recent versions?).

There is specific code to deal with IE8 so I'm afraid it's a limitation of that browser. If we remove the 'href' then the cursor doesn't appear.

How do you do the drag&drop of these areas?

Koen

Actions
Copy link
 #5

Updated by Florian Ransmayr over 8 years ago

Hello Koen,

thanks for your reply.

As mentioned in the description of this ticket I could reproduce this issue with internet explorer version 10.x as well (i.e IE version 10.0.9200.17148). To reproduce this on my dev machine I used the IE developer tools and set the document mode to 10. Another way I found i At the a customer site the problem even uccures with IE version 11.0.9600.17501. With my IE version 11.0.9600.18059 everything works as expected. So very strange. For me personally I don't use the IE at all but the customer insists on using the IE.

I implemented the drag&drop or to be more correct the moving around of the areas using the mousewentdown, mousewentup and mousedragged events. The active areas are painted on a Wt::WPaintedWidget. To keep in mind I could avoid the problem using WAbstractArea::clicked().preventDefaultAction(). As far as I understand this "fix" doesn't work in combination with the mousedragged event because of the generated javascript code.

onclick function with preventDefaultAction():

function onclick(event) {
    var e = event || window.event, o = this;
    if ($(o).hasClass('Wt-disabled')) {
        Wt3_3_5.cancelEvent(e);
        return;
    }
    Wt3_3_5.cancelEvent(e, 0x2);
    Wt._p_.update(o, 's8', e, true);
}

onclick function with preventDefaultAction() AND connected mouseDragged() event:

function onclick(event) {
    var e = event || window.event, o = this;
    if ($(o).hasClass('Wt-disabled')) {
        Wt3_3_5.cancelEvent(e);
        return;
    }
    if (Wt3_3_5.dragged())
        return;
    Wt3_3_5.cancelEvent(e, 0x2);
    Wt._p_.update(o, 's9', e, true);
}
Actions
Copy link
 #6

Updated by Florian Ransmayr over 8 years ago

Sorry miss-clicked and activated OK instead of preview...

So here you can see that if the mouse is dragged the cancelEvent function is not reached as the onclick functions returns earlier.

I hope my explanations helps somehow.

Thanks and best regards

Florian

Actions
Copy link
 #7

Updated by Florian Ransmayr over 8 years ago

Hey koen,

to test this issue with different version of IE I used a virtual machine you can download at https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/. I used the "IE10 on Win7" that contains the IE version 10.0.9200.17148 as mentioned in a previous post.

Maybe that helps to reproduce this issue.

Best regards

Florian

Actions
Copy link

Also available in: Atom PDF