Bug 150

Это из главного меню? Мне воспроизвести не удалось. 

Нужно проверить для 1.0.3 

в 1.0.3 проблема осталась

В 1.0.6 проблема с фокусом осталась, хотя теперь показывается каждый пункт меню.

Нужно проверить, наверное всё нормально теперь?

принял, проверю.

Посмотрел, проблема осталась, при возврате из подменю, в меню, главное окно теряет фокус.

в 1.0.7 так же осталась проблема с субменю.

Сделать к 1.0.7 не получилось из-за проблемы с локальным ключом 1C 8.0

Поступило сообщение "В менеджере Fluxbox такой эффект отсутствует."
Возможно стоит проверить без оконного менеджера, чтобы избежать его влияния.

Увидел. 
Главное окно теперь не теряет фокус. А с субменю проблема осталась.

В данный момент ситуация следующая :
1. Фокус нигде не теряется.
2. При работе с меню, где есть несколько субменю подрят при наведении на первое субменю - оно раскрывается, при наведении на следующее - реакции никакой (если кликнуть мышкой - то всё нормально раскрывается).

Считаю что причина проблемы в следующем:
Когда открыто субменю и пользователь перемещает мышку на другое субменю (выше или ниже), первое субменю не успевает уничтожится и из-за этого меню 1с игнорирует перемещение и не создаёт новое меню.

Почему-то в том случае когда не появляется субменю зацикливается посылка и обработка сообщений вида:
trace:win:GetKeyState key (0x1) -> 1
trace:win:GetKeyState key (0x2) -> 0
trace:win:GetKeyState key (0x4) -> 0
trace:message:SPY_EnterMessage (0x40030) L"{V8PopupBar}"  message [0084] WM_NCHITTEST sent from self wp=00000000 lp=021b0347
trace:message:SPY_EnterMessage     (0x40030)  DefWindowProc32: WM_NCHITTEST [0084]  wp=00000000 lp=021b0347
trace:win:GetWindowRect hwnd 0x40030 (656,370)-(930,730)
trace:message:SPY_ExitMessage      (0x40030)  DefWindowProc32: WM_NCHITTEST [0084] returned 00000001
trace:message:SPY_ExitMessage  (0x40030) L"{V8PopupBar}"  message [0084] WM_NCHITTEST returned 00000001
trace:win:WINPOS_WindowFromPoint scope 0x10020 (839,539) returning 0x40030
trace:win:GetKeyState key (0x1) -> 1
trace:win:GetKeyState key (0x2) -> 0
trace:win:GetKeyState key (0x4) -> 0

В оригинальном вайне (0.9.44) такая же проблема.

Если отключить управление окнами менеджером в оригинальном вайне, то ошибка так же проявляется.

На 1с8 локальной бага так же проявилась.

Почему-то при наведении на следующий пункт меню хендл не меняется по трейсу:
trace:menu:GetMenu for 0xa0032 returning (nil)
trace:menu:GetMenu for 0xa0032 returning (nil)
А если кликнуть - то сразу меняется...

Насчёт последнего поста - так и должно быть.

Подсоединяю два куска трейса.
Первый показывает неправильную реакцию, при котором субменю не появляется:
race:message:SPY_EnterMessage     (0x60030)  DefWindowProc32: WM_SETCURSOR [0020]  wp=00060030 lp=02000001
trace:message:SPY_ExitMessage      (0x60030)  DefWindowProc32: WM_SETCURSOR [0020] returned 00000000
trace:message:SPY_ExitMessage  (0x60030) L"{V8PopupBar}"  message [0020] WM_SETCURSOR returned 00000000
trace:message:SPY_EnterMessage (0x60030) L"{V8PopupBar}"  message [0200] WM_MOUSEMOVE dispatched  wp=00000000 lp=00760067
trace:win:TrackMouseEvent 10, 2, 0x60030, 4294967295
trace:message:SPY_EnterMessage     (0x60030) L"{V8PopupBar}"  message [0084] WM_NCHITTEST sent from self wp=00000000 lp=01730276
trace:msg:WINPROC_CallProcWtoA (hwnd=0x60030,msg=WM_NCHITTEST,wp=00000000,lp=01730276)
trace:message:SPY_EnterMessage         (0x60030)  DefWindowProc32: WM_NCHITTEST [0084]  wp=00000000 lp=01730276
trace:win:GetWindowRect hwnd 0x60030 (526,252)-(800,612)
trace:message:SPY_ExitMessage          (0x60030)  DefWindowProc32: WM_NCHITTEST [0084] returned 00000001
trace:message:SPY_ExitMessage      (0x60030) L"{V8PopupBar}"  message [0084] WM_NCHITTEST returned 00000001
trace:win:WINPOS_WindowFromPoint scope 0x60030 (630,371) returning 0x60030
trace:win:TrackMouseEvent point (630,371) hwnd 0x60030 hittest 1
fixme:win:TrackMouseEvent
Can not find!59
trace:msg:KillSystemTimer 0x60030 2127243020
fixme:win:alloc_winproc Go to this1
trace:win:alloc_winproc reusing 0xffff0090 for 0x7ec2d480/(nil)
fixme:win:alloc_winproc Go to this2
trace:msg:SetSystemTimer Added 0x60030 7ecb270c 0xfff

Во втором - кусок трейса при котором создаётся субменю:
trace:message:SPY_EnterMessage (0x30042) L"{V8MDIClient}" message [0200] WM_MOUSEMOVE dispatched  wp=00000000 lp=00360015
trace:message:SPY_EnterMessage     (0x30042)  DefWindowProc32: WM_MOUSEMOVE [0200]  wp=00000000 lp=00360015
trace:message:SPY_ExitMessage      (0x30042)  DefWindowProc32: WM_MOUSEMOVE [0200] returned 00000000
trace:message:SPY_ExitMessage  (0x30042) L"{V8MDIClient}" message [0200] WM_MOUSEMOVE returned 00000000
trace:msg:peek_message got type 6 msg 113 (WM_TIMER) hwnd 0x10028 wp 50cfeea lp ffff0026
trace:msg:peek_message got type 6 msg 113 (WM_TIMER) hwnd 0x10028 wp 50cfeea lp ffff0026
trace:win:GetKeyState key (0x1) -> 1
trace:win:GetKeyState key (0x2) -> 0
trace:win:GetKeyState key (0x4) -> 0
trace:message:SPY_EnterMessage (0x30042) L"{V8MDIClient}" message [0084] WM_NCHITTEST sent from self wp=00000000 lp=016b0144
trace:msg:WINPROC_CallProcWtoA (hwnd=0x30042,msg=WM_NCHITTEST,wp=00000000,lp=016b0144)
trace:message:SPY_EnterMessage     (0x30042)  DefWindowProc32: WM_NCHITTEST [0084]  wp=00000000 lp=016b0144
trace:win:GetWindowRect hwnd 0x30042 (301,307)-(1146,833)
trace:message:SPY_ExitMessage      (0x30042)  DefWindowProc32: WM_NCHITTEST [0084] returned 00000001
trace:message:SPY_ExitMessage  (0x30042) L"{V8MDIClient}" message [0084] WM_NCHITTEST returned 00000001
trace:win:WINPOS_WindowFromPoint scope 0x10020 (324,363) returning 0x30042
trace:x11drv:X11DRV_ShowWindow hwnd=0x10028, cmd=0, wasVisible 0
trace:msg:peek_message got type 6 msg 113 (WM_TIMER) hwnd 0x10028 wp 50cfeea lp ffff0026
trace:msg:peek_message got type 6 msg 113 (WM_TIMER) hwnd 0x10028 wp 50cfeea lp ffff0026
trace:win:GetKeyState key (0x1) -> 1
trace:win:GetKeyState key (0x2) -> 0
trace:win:GetKeyState key (0x4) -> 0
trace:win:WINPOS_WindowFromPoint scope 0x10020 (262,355) returning 0x10020
trace:x11drv:X11DRV_ShowWindow hwnd=0x10028, cmd=0, wasVisible 0
trace:msg:peek_message got type 6 msg 113 (WM_TIMER) hwnd 0x60030 wp 2 lp 0
trace:msg:peek_message got type 6 msg 113 (WM_TIMER) hwnd 0x60030 wp 2 lp 0
trace:message:SPY_EnterMessage (0x60030) L"{V8PopupBar}"  message [0113] WM_TIMER dispatched  wp=00000002 lp=00000000
trace:msg:KillTimer 0x60030 2
trace:win:WIN_CreateWindowEx "" "V8PopupBar" ex=00000008 style=86000000 0,0 0x0 parent=0x60030 menu=(nil) inst=0x20fc0000 params=(nil)
trace:win:dump_window_styles style: WS_POPUP WS_CLIPSIBLINGS WS_CLIPCHILDREN
trace:win:dump_window_styles exstyle: WS_EX_TOPMOST

Ещё заметил такой эффект:
если задержать мышку на том пункте меню, что не открылось, а должно было открыться. Подождать несколько секунд (около 10), затем её подвигать в этом же пункте меню, то после этого оно открывается.

В Windows новое меню иногда появляется быстрее, чем уничтожается старое (это наблюдение при работе с 1с) 

Чёрте что, иногда всё работает нормально, иногда нет. Такое подозрение, что тут дело ещё и в том, что я не локально всё запускаю.

Буз управления окнами эта бага лучше воспроизводится.

Заметил, что в иксовой обработке отдачи фокуса окну, есть комментарий о том, что мы вынуждены симулировать клик мышкой по заголовку для наших внутренних целей. С учётом того, что у меня сложилось ощущение после исследования ошибки о том, что не передаётся движение курсора окну меню, я симулировал сдвиг мышки на один пиксель вправо и на один вниз. Благодаря этому, сообщение о передвижении мышки стало приходить в 1с и после этого подменю стало открываться. 

Этот хак я добавил к winex11.drv-fix1c80.patch. Работает только для всплывающих окон 1с 8.1/8.0

Все остальные проблемы с меню описаны в 729 баге, вот её я и буду сейчас исправлять.

Переделал хак..

Исследования показали, что проблема заключается в том, что при работе меню 1с 8.1 постоянно при перемещении из одного пункта меню в другой создаётся два таймера с id 2 и 3 соответственно. 2 таймер отвечает за проверку того, что указатель отстоял на одном и том же месте указанный срок и после этого начинает процесс создания всплывающего пункта меню. 3 таймер отвечает за закрытие уже открытого в предыдущем случае пункта меню.

Ошибка заключается в том, что эти два таймера создаются с одинаковым таймаутом одновременно и поэтому сначала уничтожается 2,а затем 3. Из-за этого 1с думает, что предыдущее меню ещё не закрыто и поэтому не начинает создания нового пункта меню. Если принудительно сделать так, что 2 таймер уничтожается после 3, то всё начинает работать нормально.