FWD » Core Development » User Interface

Clicking on the minimized caption button can invoke the resize action for the window under the caption button if the minimized window is on the top of the other. It looks like the corresponding mouse events are bubbled and caught by the next listener. In the considered case it is a resize listener.

The current version 1811u has the following issue if we minimize the top most window of equal-sized stacked windows, then all windows are minimized. It can be reproduced for the ./demo/simple_windows.p

If you do this by pressing the minimize caption button, then this might be a problem of "leaking" the event to windows underneath the top one. Only one window should treat the event (the topmost one, under the location of the mouse).

Yes, agree. WindowStateChangedWorker registers "dblclick", "click", "mousedown", "mouseup" listeners. If windows are stacked, then the top most window gets "mousedown" and invoke the "minimize" action, but then "mouseup" listener of the second window handles "mouseup" event and executes the "minimize" action.

In this case the top window is collapsed, but the second window becomes the top window and gets "mouseup" event. I investigated this case with Firefox by logging and it couldn't be watched by setting the break point.

Hm... I think we need to find a way so that all the mouse events (down, up, click, dblclick) work with the same initial source, and don't re-compute the source for each event.

Planning to dispatch mouse events via a global document listener, MouseEventDispatcher from p2j.screen.js.

According to the tests performed for Firefox and Chromium these browsers support the determined sequence of the following mouse events: mousedown, mouseup and click. If we press the left mouse button within the browsers window and release it out the browser, then the global document listener for these events catches events in a sequence: mousedown, mouseup and click. Thus it can be used to determine the target window that continues to be valid during this events circle. This target window will be used to fix this bug's issue.

The other solution to use the global dispatcher differs from the existing design. MouseEventDispatcher can dispatch mousedown, mouseup and click events to the registered OS events handlers: WindowIconify, WindowMaximize and WindowClose, but this design requires to move the others OS events handlers: MouseMovable, MousePopupable and MouseEditable to use the global dispatcher.

The current progress state is that WindowIconify, WindowMaximize, WindowClose, MouseMovable, MousePopupable (except MouseEditable that is invoked from MouseHandler) and MouseResizable are forced to use the global dispatcher. MouseMovable and MouseResizable are in progress.

It is possible to delegate this code

      // register default mouse listeners last
      for(var mouseOp in mouseOps)
      {
         if (mouseOps.hasOwnProperty(mouseOp))
         {
            // cannot use an array here because some indexes are negative numbers
            this.mouseAwareWidgets[mouseOp] = {};
            if (mouseOp !== "drag" && mouseOp !== "click" && mouseOp !== "mouseup" && mouseOp !== "mousedown")
            {
               this.canvas.addEventListener(mouseOp, this.raiseMouseEvent(this, mouseOp));
            }
         }
      }

Vadim, could you help what mouse events are listen by popups? I am doing changes for the web client to dispatch the target mouse events using the global dispatcher?
For an example, the popup menu is opened on clicking the right mouse button and if the mouse is over this popup, then its menu item is highlighted. And if the mouse is down out of this popup, then it is closed. Please give me a direction what java ui classes are responsible for popups and their mouse events handling?

Nevermind, I found MousePopupable and the other related classes.

Sergey, the changes in 1811u rev 11012 make sense. The only question is this: you are assuming the Window's name (i.e. the canvas with the P2J Window, correct?) will contain the ID and will use the pwindow_<id> format. But what about this code:

options.id     = options.id    || ("pwindow_" + wid);

Wouldn't this allow the id to be specified via some external configuration, which might not follow this pattern?

Constantin Asofiei wrote:

Sergey, the changes in 1811u rev 11012 make sense. The only question is this: you are assuming the Window's name (i.e. the canvas with the P2J Window, correct?) will contain the ID and will use the pwindow_<id> format. But what about this code:
[...]

Wouldn't this allow the id to be specified via some external configuration, which might not follow this pattern?

Since all windows created by our API satisfy this pattern "pwindow_", we can fix this by options.id = "pwindow_" + wid;. Now I am doing the proposal in note 12. There are difficulties. One is the OS widgets are processed differently from the mouse widgets and it can be fixed by adding the OS widgets to mouse widgets list, because all of them now get mouse events from MouseEventsDispatcher. Planning to fix them today and to prepare the code for the review.

We can use a map of custom html element's ids to their application window's ids in order to fix the usage of "pwindow_" + wid.

Committed revision 11015 has small fixes for misspelled listen event of MousePopupable and incorrectly built event's object of MouseMovable.

Planning to rebase to the current P2j trunc.

Now 1811u is from 11006 rev of trunc and is pushed up to revision 11021.

Committed revision 11037 minimizes a target window on mouseup. The bug scenario described in note-1 can't be reproduced on the current version.

Can I close this?

Yes, because the note-1 isn't reproduced.