Its correctly a modal dialog. I think the problem you have is "attached modal dialog" and the default behaviour under gnome is to lock the modal dialog to the thing its modal for so if you move the dialog everything moves with it. The "lock" behaviour isn't our behaviour but enforced on modal dialogs.

gnome-tweak-tool under windows->attached modal dialog can be used to disable this globally.

I see no reason why this dialog should be modal. Transient/child of the main window? Yes. "Utility" type hint? Yes. Modal? Nope.

Unless you provide the chart preview directly into the dialog instead of behind it onto the spreadsheet in a place that I can't control...

OK, this problem still f$%?$%s with me daily, half a decade later. GNOME's behavior is the default on all major Linux distros (including Ubuntu now) and GNOME is the most widely used DE, so I'm reopening under a different angle then: if you don't want to simply make this dialog non-modal (I still see no reason why it should be modal, at all), then the live preview should be inside the chart wizard/dialog instead of sitting at some random place on the spreadsheet behind it.

Created attachment 165285 [details]
Demonstration of the problem using the GTK Inspector

I had a "How Hard Can It Be?™ " moment where I thought "This might be a one-liner fix to make it non-modal", and so I ran "git grep -i modal chart2/" which gave me this:

    chart2/source/controller/dialogs/dlg_CreationWizard_UNO.cxx: void SAL_CALL CreationWizardUnoDlg::startExecuteModal(blah blah blah)
    chart2/source/controller/dialogs/res_ErrorBar.cxx:    pWeldDialog->set_modal(!bEnable);
    chart2/source/controller/dialogs/tp_DataSource.cxx:    pDlg->set_modal(!bEnable);
    chart2/source/controller/dialogs/tp_RangeChooser.cxx:        pDlg->set_modal(!bEnable);
    chart2/source/controller/inc/dlg_CreationWizard_UNO.hxx:    virtual void SAL_CALL startExecuteModal(blah blah blah)
    
    chart2/uiconfig/ui/3dviewdialog.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/attributedialog.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/chartdatadialog.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/charttypedialog.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/datarangedialog.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/dlg_InsertErrorBars.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/dlg_InsertLegend.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/insertaxisdlg.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/insertgriddlg.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/inserttitledlg.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/smoothlinesdlg.ui:    <property name="modal">True</property>
    chart2/uiconfig/ui/steppedlinesdlg.ui:    <property name="modal">True</property>

I thought the fix could simply be to remove (or comment out, on my Fedora system's installed files in /usr/lib64/libreoffice/share/config/soffice.cfg/modules/schart/ui/ ...) the '<property name="modal">True</property>' lines for chartdatadialog.ui, datarangedialog.ui, charttypedialog.ui, but it doesn't seem to actually make them non-modal in practice... As if some part of the code overrides all of that, maybe those "startExecuteModal" function calls? If so that's beyond my simple tinkering ability, but I suspect it would still be fairly easy to solve for an experienced LibreOffice contributor. I do think making all the "large view-blocking dialogs that should not block the view because the chart preview depends on that" non-modal is the easiest and most reasonable approach (bonus points for setting the dialogs' position to avoid overlapping the chart by default, ideally)

Confirming that it's still a problem with:

Version: 7.5.3.2 (X86_64)
Build ID: 50(Build:2)
CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: fr-CA (en_CA.UTF-8); UI: en-US
Calc: threaded