Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find/replace overlay: find-dialog are resized unnormally if it is used for MD-files #2147

Closed
Tracked by #2021
speckyspooky opened this issue Aug 1, 2024 · 5 comments · Fixed by #2154
Closed
Tracked by #2021
Labels
bug Something isn't working

Comments

@speckyspooky
Copy link

Steps to reproduce

I use the eclipse version 2024-09. The problem is when the Find/Replace-dialo will be opend on an md-file
the sizing of the dialog is unnormally huge.
Additional on it there is a difference between the "Markdown Source" and the "Preview".
If the find dialog is started at the preview-register a mix of old and new search is shown.

###MD-file, "Markdown Source" register, opened find-dialog

grafik

###MD-file, "Preview" register, opened find-dialog
grafik

Tested under this environment:

  • MS Windows 11
  • Eclipse IDE/Platform version: Version: 2024-09 M1 (4.33.0 M1)
  • Build id: 20240711-1605
@speckyspooky speckyspooky added the bug Something isn't working label Aug 1, 2024
@merks
Copy link
Contributor

merks commented Aug 1, 2024

I’ve seen that too. I’m not sure if that’s a Mylyn problem. It’s always been a problem that two find dialogs open depending on which tab is open.

@HeikoKlare
Copy link
Contributor

Thank you for reporting that issue. It is still reproducible with recent I-Builds? We have fixed several problem with respect to to sizing and placement since M1, so the issue might have been already been resolved.
Do you have any extensions installed for opening the markdown file? I would like to reproduce the issue, but with the given information I was not yet able to do so.

@merks
Copy link
Contributor

merks commented Aug 2, 2024

Here's a trick that I use to get something else into the target platform. Use Navigate -> Open Setup -> Workspace and copy and paste this text onto the Workspace instance and save it:

<?xml version="1.0" encoding="UTF-8"?>
<setup.targlets:TargletTask
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:setup.targlets="http://www.eclipse.org/oomph/setup/targlets/1.0"
    xsi:schemaLocation="http://www.eclipse.org/oomph/setup/targlets/1.0 https://raw.githubusercontent.com/eclipse-oomph/oomph/master/setups/models/SetupTarglets.ecore">
  <targlet name="Mylyn">
    <requirement
        name="org.eclipse.mylyn.wikitext.feature.feature.group"/>
    <repositoryList>
      <repository
          url="https://download.eclipse.org/mylyn/updates/nightly/latest"/>
    </repositoryList>
  </targlet>
</setup.targlets:TargletTask>

Then use Help -> Perform Setup Tasks to perform the Modular Targlet tasks, with such that the Mylyn feature is in the target platform. Launch a runtime workspace with this feature included in the launch. Then you can open a *.md file with the Mylyn editor to see how it works with the latest SDK source.

HeikoKlare added a commit to HeikoKlare/eclipse.platform.ui that referenced this issue Aug 4, 2024
…lipse-platform#2147

The FindReplaceOverlay currently expects a target control that is an
instance of Scrollable to provide a horizontal and vertical scrollbar.
This is invalid, as per API the according getter methods do not
necessarily return scrollbars. In consequence, exceptions occur that
lead to an improperly positioned overlay, as the update callback for the
position and size aborts.

This change ensures that scrollbars of the target control are only
considered when available.

Fixes eclipse-platform#2147
@HeikoKlare
Copy link
Contributor

Thank you, @merks! With your trick, I was able able to reproduce the issue within the blink of an eye :-)

@speckyspooky the issue you reported is still present in the current development state. It reveals a bug in the find/replace overlay implementation. Thanks again for reporting it! I have proposed a fix in #2154.

Note that this will not have any effect on the different find/replace UIs in the source and preview tabs, which is because the source tab uses the Eclipse-integrated search functionality while the preview tab uses the browser-integrated one (IE or Edge, depending on what is used). Just like before, the find/replace bar of one tab will stay open when switching to the other tab, which seems to be caused by the Mylyn markdown editor not using a multi-page editor but some "custom" implementation for showing multiple tabs.

@speckyspooky
Copy link
Author

Thanks for your fast fixing!

lathapatil pushed a commit to lathapatil/eclipse.platform.ui that referenced this issue Oct 21, 2024
…lipse-platform#2147

The FindReplaceOverlay currently expects a target control that is an
instance of Scrollable to provide a horizontal and vertical scrollbar.
This is invalid, as per API the according getter methods do not
necessarily return scrollbars. In consequence, exceptions occur that
lead to an improperly positioned overlay, as the update callback for the
position and size aborts.

This change ensures that scrollbars of the target control are only
considered when available.

Fixes eclipse-platform#2147
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants