From Writer: menu - Insert / Special Character / subset: Basic Hebrew / HEBREW ACCENT OLE (U-5AB / 1451) / r-click / Copy to Clipboard / Cancel frequently hangs on Special Characters window & never returns to Writer. Must force quit, restart Writer & recover document
Why would you 'Right click copy to clip board'--what is your Special Character work flow after the copy? The Insert button will place the glyph directly to canvas using the font selection made. The copy on clipboard will not have any font associated--so will depend on where you would be putting from clipboard--and what format (clipboard format CF_TEXT or CF_UNICODETEXT).
I do this in order to then repeatedly insert the character into the middle of my Hebrew text in various locations - often as an accent mark in the midst of a teaching text. I've been doing this for about a year, and it's only recently that it often (but not always) hangs. Otherwise, I have to go through the extensive menu steps leading to "insert" for each insertion which is quite unwieldy. In the past, I used direct Unicode Alt keystrokes to generate the accent character, but my current keyboard doesn't seem to support that.
(In reply to Rachmiel Langer from comment #2) > I do this in order to then repeatedly insert the character into the middle > of my Hebrew text in various locations - often as an accent mark in the > midst of a teaching text. I've been doing this for about a year, and it's > only recently that it often (but not always) hangs. > > Otherwise, I have to go through the extensive menu steps leading to "insert" > for each insertion which is quite unwieldy. In the past, I used direct > Unicode Alt keystrokes to generate the accent character, but my current > keyboard doesn't seem to support that. OK, there could of course be an issue with the Special Character dialog. But as an alternative work flow--do your copy from your document canvas after the initial paste or Unicode toggle. That is type the Unicode "U+05ab", or other codepoint as needed, and position the cursor at the end of the string. An <Atl>+X will toggle to the glyph either using the current paragraph font--or use the operating system's fallback for the glyph as appropriate to the paragraph. That glyph copied to clipboard will persist--until a different selection is copied to clipboard. Of course it is a combining glyph--so you may still have to use the Special Character dialog as a insert picker, or input the Unicode from keyboard and convert.
Because it's a combining glyph, it's not possible to copy it separately from the document canvas. And, as I indicated, my current keyboard doesn't support direct typing of Unicode U+05ab (previous one did fine, but died). Currently, the only way to insert the character is "insert" from the Special Characters window, or "copy to clipboard" from that window (for multiple inserts) - and that's where the recent crash occurs. Using "insert" from Special Characters doesn't automatically copy the character to the clipboard, so it's either go through all the steps to "insert" or attempt copy to clipboard with frequent risk of crash. Actually inserting the character into the text is working fine (inserted into appropriate positions embedded in Hebrew text), as has been all along. The problem is the new issue of Special Characters dialog window not closing and returning control.
Getting away from issue of a hang, which I've not been able to reproduce. The Special Character Dialog was welded with https://gerrit.libreoffice.org/c/core/+/52084 But in testing 7.0.0rc3 and recent 7.1.0 masters using the dialog's 'Insert' button pastes the indicated glyph from the character map, or the 'Favorite Characters' bar, or the 'Recent Characters' bar. The dialog then closes. The Special Character dialog is intended to remain open for insertion of multiple characters each performed with a 2-click on the charmap or from one of the bars. Exit from the dialog is with the 'Close' button. So, without specific steps that reproduce (STR)--we are stuck. (In reply to Rachmiel Langer from comment #4) > Because it's a combining glyph, it's not possible to copy it separately from > the document canvas. Just put it in a paragraph of text by itself. Either 2-click insert it from Special Character dialog (and Close the dialog), or convert from the typed string "U+05ab" with <Alt>+X. The glyph will be available for selection, copy and multiple pastes. Trick is to select that paragraph with the single glyph with 3-click mouse paragraph selection. <Ctrl>+C to copy to clipboard. Delete the scratch paragraph when done. > And, as I indicated, my current keyboard doesn't > support direct typing of Unicode U+05ab (previous one did fine, but died). > Currently, the only way to insert the character is "insert" from the Special > Characters window, or "copy to clipboard" from that window (for multiple > inserts) - and that's where the recent crash occurs. Using "insert" from > Special Characters doesn't automatically copy the character to the > clipboard, so it's either go through all the steps to "insert" or attempt > copy to clipboard with frequent risk of crash. > Have you tried the <Alt>+X (which has been localized for a few locales) Unicode toggle LibreOffice provides? > Actually inserting the character into the text is working fine (inserted > into appropriate positions embedded in Hebrew text), as has been all along. > The problem is the new issue of Special Characters dialog window not closing > and returning control. OK, so that could happen if the 'Insert' button action is somehow mishandled. But need STR.
> So, without specific steps that reproduce (STR)--we are stuck. First thing I reported were specific steps that frequently lead to this hang. Crucial point within Special Characters window is right-clicking on character and then choosing 'copy to clipboard'. After that, neither Insert nor Cancel close the window. Seems to be more prevalent with subsequent opens of Special Characters window to reselect special character (after clipboard used for other copy), but hang occurs quite frequently.
OK, I can replicate the hang. Looks to be XClipBoard -> system clipboard related on Windows [1] Attaching a pair of WinDbg stack traces taken w/break when the hang occurs after the context menu copy to clipboard hangs. STR were a bit spurious, and may be dependent on having another app attached to system clipboard (I had the NirSoft InsideClipboard applet running to monitor the clipboard) and that contention may be issue. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/svx/source/dialog/charmap.cxx?r=b4f398db#257
Created attachment 163981 [details] UI hang on Special Character dialog context menu 'copy to clipboard' two WinDbg ST on break
I'm not sure why I'm cc'ed on this bug ? But the initial reports states it hangs *after* cancel on the dialog is pressed and comment #8 states it hangs at "copy to clipboard" with a clipboard monitor installed which might be different things. I cannot reproduce on a bare windows install. caolanm->rlanger: Do you have any sort of extra clipboard related monitor installed ?
(In reply to Caolán McNamara from comment #9) > I'm not sure why I'm cc'ed on this bug ? But the initial reports states it > hangs *after* cancel on the dialog is pressed and comment #8 states it hangs > at "copy to clipboard" with a clipboard monitor installed which might be > different things. The OP modified that comment 6. And I experienced the hang--after the context menu copy. Seemed only recent changes here were the Weld. I hoped the ST might make the glitch obvious. Seems similar to clipboard deadlock in Mike K's https://gerrit.libreoffice.org/c/core/+/94679 as tweaked with https://gerrit.libreoffice.org/c/core/+/95088 > > I cannot reproduce on a bare windows install. For me just 2 out of 10, but with the NirSoft clipboard monitor running... > > caolanm->rlanger: Do you have any sort of extra clipboard related monitor > installed ? => NEEDINFO
No clipboard utility of any kind installed that I'm aware of. Standard Dell installation of Win 10. Only software changes I can point to are relatively frequent Dell Windows updates.
Version 7.1.3 has some Windows clipboard related improvements. Could you try to reproduce your bug with it? Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Just tested it and the issue still occurs.
Rachmiel, a new major major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Rachmiel Langer, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Under spot testing, seems to be working OK under 7.4.5.1 but since problem was always intermittent cannot conclusively call it fixed. FYI, (unrelated) - Insert button is not applying font specified in Special Characters window. Copy to clipboard & insert in document is assigning (same) font of context text.
(In reply to Rachmiel Langer from comment #16) > Under spot testing, seems to be working OK under 7.4.5.1 but since problem > was always intermittent cannot conclusively call it fixed. So let's close it for the moment. Fell free to change it back to UNCONFIRMED, if problem appears again.