Project

General

Profile

Bug #3640

using font or color choosing dialogs more than once in the web client hangs the client

Added by Greg Shah about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Ovidiu Maxiniuc
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to User Interface - Feature #3261: enhanced browse that can optionally selected as a replacement for the default ABL browse Closed

History

#1 Updated by Greg Shah about 8 years ago

This was easily recreated using the enhanced browse (#3261), when in "Change Layout" mode. Open the color or font dialog. Close it. Then try to open it again. The UI will hang and the session had to be closed.

#2 Updated by Greg Shah about 8 years ago

  • Related to Feature #3261: enhanced browse that can optionally selected as a replacement for the default ABL browse added

#3 Updated by Ovidiu Maxiniuc about 8 years ago

This seems to be a strict web/js issue. The Swing driver works fine.

#4 Updated by Ovidiu Maxiniuc about 8 years ago

I did a bit of JS debugging. I see the following message printed in JS console when the second color chooser is shown:

Deregister dead widgets failed for undefined window -479

I came from common/p2j.socket.js:2327:20 when theWindow is null/not found on a PROCESS_MOUSE_WIDGETS event.

Then bellow I have another message: 

unknown window: -481

The window that backs the dialog has id: -483.

#5 Updated by Ovidiu Maxiniuc about 8 years ago

Apparently the problem is not on JS side, but it looks to be on WebDriver, it does not supply the updated mouse widgets when the new dialog is shown. I am investigating the registerMouseWidgets() and the updates of registerMouseWidgets flag which governs it.

#6 Updated by Ovidiu Maxiniuc about 8 years ago

I fixed the issue by forcing WebDriver to resend mouse-sensitive widgets list for system dialogs.
Committed to 3261c in rev 11294.

Note that the warnings that were misleading me (in note-4) are still present.
I also noticed some other behaviour: when the change-layout menu was displayed, the areas of the menu items overlapping the browse were not sensitive to mouse move/click. Ie, I was unable to select menu items or click them unless the mouse pointer was outside the area bounding the edited browse. I think this is similar with #3581. That seems to be fixed in 3600a but I did not test with this branch yet.

#7 Updated by Ovidiu Maxiniuc about 8 years ago

  • Status changed from New to WIP
  • % Done changed from 0 to 90

#8 Updated by Eric Faulhaber about 8 years ago

  • Assignee set to Ovidiu Maxiniuc

#9 Updated by Ovidiu Maxiniuc about 8 years ago

I copied the code from 3261c to 3600b but I don't know how to test this.
I know that it was working with 3261c (where the dialogs were used for customizing the browses) but I am not committing it before testing it in the new environment.

LE: maybe I was not very clear: where is a modal system dialog used in customer client?

#10 Updated by Eric Faulhaber about 8 years ago

Task branch 3600b was merged to trunk revision 11273. Can this be closed?

#11 Updated by Ovidiu Maxiniuc about 8 years ago

I successfully tested the update with injected code and then with scenario encountered by Eric and communicated by private email.

As result, this tracker can be closed.

#12 Updated by Eric Faulhaber about 8 years ago

  • % Done changed from 90 to 100
  • Status changed from WIP to Closed

Also available in: Atom PDF