Bug 365280

Comment 1 wuzhe 2011-12-01 04:12:36 EST

Created attachment 207782 [details]
Sample

Sample

Comment 2 Silenio Quarti 2012-02-01 14:54:52 EST

Grant, this happens to on Lion just after running the snippet (no need to select all, copy, etc). Please investigate.

Comment 3 Grant Gayed 2012-05-23 22:41:22 EDT

Sorry, I spent time investigating this earlier in the cycle but I was not able to make a fix.  Targeting for 4.2.1, which will be the next service release.

Comment 4 wuzhe 2012-05-23 23:04:20 EDT

Hi Grant,

As this bug is top sev-1 SPR for Notes, we are eager to a fix. Could you spend some more time to have a look? And we found some hint for it, yesterday, our Lotus Notes Mac team Dev found that it's related to a well known Mac bug as below: 
"
NSComboBox popup getting dismissed on NSApp postEvent

https://discussions.apple.com/thread/2188281?threadID=2188281&tstart=-5

apparently this is cause in what i believe is a bug in NSComboBox. NSComboBox starts its own event processing loop and when you use NSApplicationDefined events it closes the NSComboBox. only thing you can do is build into your architecture that events that use NSApplicationDefined are not sent while a NSComboBox is open.

It seems the application defined event sent via NSApp postEvent by XULRunner caused this. Workaround is to fix XULRunner to not post the event while a NSComboBox is open.
"

Comment 5 Grant Gayed 2012-05-24 11:55:16 EDT

(In reply to comment #4)

That certainly sounds similar to what we're seeing.  Someone else reports something similar: http://lists.apple.com/archives/cocoa-dev/2005/Apr/msg01456.html .

I've tried a workaround that eats all NSApplicationDefined events passing through our loop but it doesn't seem to help.  The closing of the combo is often accompanied by an NSApplicationDefined event soon after, but not always.  Still looking.

Comment 6 Jun Yue Liu 2012-05-24 12:31:52 EDT

(In reply to comment #5)

I changed all the 3 of [NSApp postEvent:...NSApplicationDefined...] to [NSApp postEvent:...NSSystemDefined...], and rebuilt a XULRunner-1.9.2.10 binary runtime.  Such change did fix the problem.

But not sure if such kind of change will conflic with other Apple built-in NSSystemDefined event.  It will be better if we can workaround by modifying SWT code, instead of xulrunner code.

Comment 7 Grant Gayed 2012-05-24 15:38:07 EDT

(I'm using XULRunner 10)

The second postEvent: in nsAppShell::ProcessGeckoEvents() is where the problematic event is posted.  These particular events are triggered by a timer.  Most events posted from here reach SWT's event loop without problem, but these ones do not.  XULRunner contains some #nextEventMatchingMask()s invoations, but they do not appear to be eating these disappearing events.

So either swt is somehow failing to access all events in the loop (eg.- are they posted on another thread?), or the events are being eaten somewhere before swt has a chance to see them.  If they are being eaten then I don't think this is fixable in swt.  However the first possibility needs further investigation.

Comment 8 Grant Gayed 2012-05-28 16:32:45 EDT

Fixed > 20120528, patch: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=1587016128f120779b698d8ab37efa85ed9c8e7c .

Comment 9 Jun Yue Liu 2012-05-28 22:15:22 EDT

(In reply to comment #8)

Hi Grant,
Would you please confirm if above link is to the fix for this bug #365280? Could you summary how this is fixed?

Comment 10 Grant Gayed 2012-05-29 00:12:20 EDT

Sorry, wrong link to the patch, it should be: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=f892b6419893d6fb0c860079de38ff367a495210 .  (I assume this was the source of the confusion).

Comment 11 Jun Yue Liu 2012-05-29 05:11:46 EDT

(In reply to comment #10)
Grant, Thanks for your patch.   But it look like that the code of mozillaCount is not needed.  Because, even all browser are disposed, the Mozilla event loop will be still active and there will be still some nsApplicationDefined event.

And, it will be perfect if we can query and check the event subtype.

Comment 12 Grant Gayed 2012-05-29 06:58:11 EDT

I don't have a Mac in front of me at the moment, the following is based on what I remember from yesterday:

> Grant, Thanks for your patch.   But it look like that the code of mozillaCount
> is not needed.  Because, even all browser are disposed, the Mozilla event loop
> will be still active and there will be still some nsApplicationDefined event.

The goal is to run the workaround in Display as infreqently as possible.  At a minimum, only running it after a Mozilla-style Browser has been created ensures that it does not run in SWT's 99% case, which is no Mozilla-style Browser created on Mac (most apps, including Eclipse, only create Browsers with style SWT.NONE).  Also, not running the workaround when the Mozilla Browser count goes from > 0 to 0 worked well yesterday when I modified the test snippet to create/destroy Browser instances as requested.  The workaround was not needed after the Browser on the test page was disposed.

> And, it will be perfect if we can query and check the event subtype.

We looked at the Mozilla NSApplicationEvent subtypes during yesterday's investigation and they were always 0, which does not seem useful (?).

Comment 13 Jun Yue Liu 2012-05-29 09:54:29 EDT

(In reply to comment #12)

Basing on the sample attached to this bug report, I added a button to dispose the browser. My test show that the workaround is still needed after browser is disposed.   I guess the different test results may be caused by various xulrunner version.

For the NSApplicationDefined post by XULRunner, all subtype is 0.  I assume that other NSApplicationDefined events are likely post with a different subtype.

Comment 14 Grant Gayed 2012-05-29 10:50:16 EDT

I've released an update to the fix, the patch is http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=aed115314f5d03f242d0bf452d6cae2ebf4a5d20 .  Once a Mozilla-based Browser is created then the workaround remains until execution is complete.

The subtype check was not added because the NSCombo behaviour would be affected by any NSApplicationDefined event, not just one originating in XULRunner.