Issue 125531 - Some sub-windows (Spell check, etc.) do not behave consistently
Summary: Some sub-windows (Spell check, etc.) do not behave consistently
Status: RESOLVED FIXED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: 4.1.1
Hardware: All OS/2
: P3 Minor (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 126518
  Show dependency tree
 
Reported: 2014-08-28 14:52 UTC by Lewis Rosenthal
Modified: 2020-10-19 17:42 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.1.7
Developer Difficulty: ---


Attachments
Buttons displaced at bottom of spell check dialog (6.61 KB, image/png)
2014-08-28 14:52 UTC, Lewis Rosenthal
no flags Details
Spell check window appearing as in the background when really in the foreground. (6.35 KB, image/png)
2014-08-28 14:53 UTC, Lewis Rosenthal
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Lewis Rosenthal 2014-08-28 14:52:23 UTC
Created attachment 83898 [details]
Buttons displaced at bottom of spell check dialog

The subject might need some refinement.

Note the attached screenshots. In one case (Spelling_window_out-of-place-buttons.png), spell check had been opened and closed several times. Buttons appear out of place (displaced) due to odd sizing of bottom of dialog.

The second case (Spelling_window_after-switching-back-to-document-then-back-to-spelling.png) occurs consistently when switching out of the spell check window and then back into it. Spell check remains functional, but window continues to appear as if in the backgorund (more Z-order-related stuff?).

Finally (here, at least), window controls do not act as expected. Rolling up the Spell check window results in the inability to roll it down afterward using the mouse. Other window controls likewise do not seem to work via the mouse (though the window can be moved by dragging the titlebar). To regain control, one must click out of the window (putting it in the background) and then click back into it (onto the titlebar, etc.), at which time, the window again behaves normally. Keyboard controls do continue to function.

Other sub-windows do not seem to exhibit this behavior (Navigator, Find & Replace).
Comment 1 Lewis Rosenthal 2014-08-28 14:53:17 UTC
Created attachment 83899 [details]
Spell check window appearing as in the background when really in the foreground.
Comment 2 Matthias Seidel 2020-03-13 16:22:08 UTC
Hi Lewis,

Case one should be fixed in AOO 4.1.8.

I can only confirm for Windows and Linux. Maybe Yuri can give you access to a test build for ArcaOS?
Comment 3 Lewis Rosenthal 2020-03-13 18:45:53 UTC
Hi, Matthias...

Well, with 4.1.7, I can no longer reproduce case 1.

The seconds case has either changed parameters or I misunderstood it when I opened this ticket. Given a document containing only:

  Heere is another misspellingk.

With the cursor after the period, starting Spellcheck, the entire line is displayed in the upper Spellcheck pane, with "Heere" in red. Clicking back into the document window, before the "H" and then clicking back to the Spellcheck dialog, it is necessary to click Resume to reactivate Spellcheck. This may just be WAD (for better or worse).

As for the third case, window rollup, this seems to be an incompatibility with the utility I generally use to perform such tasks (Styler/2). Using Xit for this task seems to work just fine, so there is likely something unexpected by Styler/2 with this window.

I'm content to resolve this as fixed, at this point.
Comment 4 Matthias Seidel 2020-03-13 18:53:20 UTC
See:
https://bz.apache.org/ooo/show_bug.cgi?id=128296

With the given steps it was reproducible with AOO 4.1.7 on Windows and Linux.