Not reproducible on Linux, marking as NEW for Windows.

I can reproduce this under windows with lang he. FWIW the LibO file-picker hasn't been converted to .ui format, so the problem is not confined to recently-converted-to-be-resizeable dialogs, but apparently all resizeable dialogs.

also appears with 3.6.4.3 with export SAL_RTL_ENABLED=1 under windows with LibreOffice (not native) filedialog.

Rainer - think we should change version to reflect Caolan's findings?

(In reply to comment #4)
Yes, of course! 

For file dialogs:
Already [Reproducible] with Server Installation of "LibreOffice 3.6.5.1 rc” Arabic UI/ German Locale [Build-ID: 5b93205]" {pull date 2013-01-18} on WIN7 Home Premium (64bit) for Files dialog (not so many resizable dialogs in 3.6)

Already [Reproducible] with server installation of "LibreOffice 3.5.7.2 rc Arabic UI/German Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit) 

Question is whether this now is a 3.6 MAB. I don't think so. Might be limited for File dialog for those older versions and so the big problem starts with 4.0!

any idea which developer we need to bug to look into this? I'm not sure who is responsible for Windows let alone dialogs like this

Caolán:
Will you proceed or is it Kendy's area?

seems to affect RTL dialog resizing all the way back to 3.3

(This is an automated message.)

Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.

Could someone please test this with 4.1 and/or 4.2 to see if it still occurs?

I received email confirmation from Andras Timar that this bug is still present in 4.1.x and 4.2.x.  moving from mab4.0 to mab4.1 list.

that message was from february 2014, would anybody please give an update with current 4.2.4.2?

if issue persists I'll move it to mab4.2 list

Moving to 4.2 mab since it was confirmed on the QA mailing list by Timar Andras

I copy and paste mailing list comment from Andras Timar which may help reproducing the bug.

.........

Yes, fdo#59613 is reproducible in 4.2 builds. It is very easy to check
it, you don't need RTL operating system or RTL UI language. Just set
the SAL_RTL_ENABLED environment variable before staring libreoffice.

Windows: start cmd, the command prompt in the 'program' directory of
LibreOffice.
> set SAL_RTL_ENABLED=1
> soffice

Linux:
$ SAL_RTL_ENABLED=1 /path/to/libreoffice/program/soffice

You'll have an English RTL UI.

Best regards,
Andras

Not reproducible with RTL (following Andras' instructions) using English UI and Portuguese Locale. Running LO 4.2.5.1 under Windows XP.

It is weird enough to use RTL with English UI. I don't dare to try Arabic or Hebrew. Sorry ;)

This is WORKSFORME but it would be better if Caolan could replicate what he did to confirm the bug. I find it unlikely that it fixed itself within branch 4.2...

Adding to the previous Comment (it is absurd that Bugzilla does not allow to edit your own comments...)

Looking at the screenshot added by Rainer, I can confirm there is a delay (many borders are drawn) when stretching the "PNG Options" dialog (but it looks ok when you release the mouse button). But the point is that the dialog should NOT be re-sizable at all!

please retest with 4.3.x or 4.4.x versions.
if issue persists, please move it to mab4.3 list since 4.2.x is EOL

TESTING with LO 4.3.5.1 on Ubuntu 14.04

(In reply to Rainer Bielefeld Retired from comment #0)
> Steps how to reproduce

(In reply to tommy27 from comment #14)
> set the SAL_RTL_ENABLED environment variable before staring libreoffice.
> 
> Windows: start cmd, the command prompt in the 'program' directory of
> LibreOffice.
> > set SAL_RTL_ENABLED=1
> > soffice
> 
> Linux:
> $ SAL_RTL_ENABLED=1 /path/to/libreoffice/program/soffice

In bash I used:
  export SAL_RTL_ENABLED=1
Then I ran the executable

> 1. Launch new Draw Document from LibO start center
> 2. draw a shape

I drew a star

> 3. Select shape
> 4. Menu 'File -> Export -> Selection -> As PNG -> <Export>

In the last step I clicked the "Save" button.

--> PNG Options Dialog will appear

> 5. Move mouse pointer to right end of dialog

Right edge?

>    > Mouse pointer view changes to "<->"

I'm sure this varies by WM (I get a pointer "->|" in Unity)

> 6. Drag and drop right dialog border slowly 40mm to the right
>    Bug: some black barcode like artivacts appear, additionally other black
>         areas and other artifacts

I see what appears like slow redraw of the right-hand edge border, but once I stop moving or release the mouse, the dialog repaints correctly.

> These problems also are visible in LTR UI, but here the problems are much
> smaller and mostly disappear short moments after mouse button has been
> released.

Yes, this description much more closely matches the behavior I see.

Same result when testing against LO 4.2.0.1

NOREPRO here. Let's test again on Windows before we resolve as WFM.

No repro on Win 7, 4.3.4.1 -> WFM.

Created attachment 110905 [details]
RTL window artifacts

I don't think it's fixed, maybe just not that bad as it was.

indeed, not so annoying like Reiner's original screenshot but still non perfect...
by the way Andras, which version did you use?

what should we do now? Reverting the status to NEW or create a brand new report with new easy reproducibility steps about the residual issue?

I got the idea that maybe I didn't get the artifacts because I did not have visual effects enabled. I tried again with them, but could not get the artifacts to appear (with Hebrew UI).