search

neo09 / gwt-platform

Automatically exported from code.google.com/p/gwt-platform
0 stars 0 forks source link

leave confirmation does not work as expected #170

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. setOnLeaveConfirmation("foo") in concrete PlaceManager
2. navigate into application with default URL (w/o anchor token), ie. 
myhost.com/myapp

What is the expected output? What do you see instead?

expected is a page load with default place revealed, but instead I got a 
confirmation with previously defined confirmation message

What version of the product are you using? On what operating system?
gwtp 0.3 on windows

Please provide any additional information below.

imho needs a special check in PlaceManagerImpl.confirmLeaveState() to know it 
user really leaves or enters the place.

Original issue reported on code.google.com by eplisc...@gmail.com on 18 Aug 2010 at 7:45

GoogleCodeExporter commented 9 years ago 
or maybe the setOnLeaveConfirmation() is intended to be called by Presenter or 
whomever everytime a check is required? If so please close this issue and maybe 
give a hint in javadoc.

btw: in most cases developers dont want their users to see native brower 
alerts() or confirm()s, so maybe you extend the API to be customizable with 
callback support (so developer can raise event controlled confirmation)

thanks

Original comment by eplisc...@gmail.com on 18 Aug 2010 at 7:55

GoogleCodeExporter commented 9 years ago 
You explained exactly the expected behavior :) But we could have a user defined 
callback, that could be a great enhancement.

Original comment by goudreau...@gmail.com on 18 Aug 2010 at 11:22

GoogleCodeExporter commented 9 years ago 
Oh yeah and the why we use the native user alerts, it's because we want the 
message to also appear when a tab is closed.

Original comment by goudreau...@gmail.com on 18 Aug 2010 at 12:28

GoogleCodeExporter commented 9 years ago 
yeah I see, not sure if all browser are compliant to allow a popup upon closing 
the window (or tab), because it could be "malicious" code not allowing the user 
to escape; actually also treated as antipattern in usability design.

yet, its up to end-developer to implement such an interception. But you're 
right, this blocking confirmation implemention shall really stay and the 
callback could be passed optionally if developer is about to provide own 
implementation?

Original comment by eplisc...@gmail.com on 18 Aug 2010 at 12:42

GoogleCodeExporter commented 9 years ago 
Not sure If I'm following you, but it isn't like a normal popup, we use 
Window.addWindowClosingHandler and should be compliant to all browser (Isn't 
this GWT job to give use function that work with any navigator ? :D).

Also noted sometimes that my message was even added to the one firefox already 
gave me ! :D

As for a callback, there's no need, implement ClosingHandler, do 
Window.AddWindowClosingHandler(this); and then add a deferred command that do 
what you want.

Ex from Gwt-Platform:
{{{
  @Override
  public final void onWindowClosing(Window.ClosingEvent event) {
    event.setMessage(onLeaveQuestion);
    DeferredCommand.addCommand(new Command() {
      @Override
      public void execute() {
        Window.Location.replace(currentHRef);
      }
    });
  }
}}}

ton unregister closing handler you can also call setOnLeaveConfirmation with 
null. 

All I said before is only for closing a tab. When it comes to cancel 
navication, we only use a simple Window.confirm window. In that case, you can 
listen for NavigationRefusedEvent.

Cheers

Original comment by goudreau...@gmail.com on 18 Aug 2010 at 1:54

GoogleCodeExporter commented 9 years ago 
Can we close this issue ?

Original comment by goudreau...@gmail.com on 25 Aug 2010 at 1:09

GoogleCodeExporter commented 9 years ago 
yes

Original comment by eplisc...@gmail.com on 25 Aug 2010 at 1:23

GoogleCodeExporter commented 9 years ago

Original comment by goudreau...@gmail.com on 25 Aug 2010 at 1:40