Skip to content
Snippets Groups Projects
  1. Mar 04, 2024
    • Benjamin Franzke's avatar
      [BUGFIX] Fix ContextMenu positioning race conditions · 99bdc230
      Benjamin Franzke authored
      Read mouse position from the triggering event instead of relying
      on values from a throttled mousemove event, which caused race
      conditions where mouse position was not updated at all when moving
      the mouse from iframe to outer frame.
      
      Resolves: #103044
      Releases: main, 12.4
      Change-Id: If22aee7eea958969fb3e7e24b15523897b70e1ef
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83185
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
      Reviewed-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
      99bdc230
    • Andreas Kienast's avatar
      [BUGFIX] Do not race tree node loading · d627a4bb
      Andreas Kienast authored
      When (de-)mounting pages in the page tree, always two requests are sent
      to the server that fetch the tree data:
      
      * when the `mountPointPath` path property is changed as it's a state
        property
      * explicitly after changing said property
      
      Especially when de-mounting a page, this tends to race conditions, as
      the mount state is additionally stored in the backend user's UC that
      needs to get unset as well.
      
      This bugfix now changes the handling when the state property, that
      triggers a re-rendering of the tree component, is updated. The
      de-mounting process now unsets the backend user's UC first and then
      changes the property to make sure that
      
      1. the state is updated once the configuration is flushed
      2. the tree nodes are fetched only once
      
      In the mounting process, the UC is correctly updated first. However, the
      state was updated and then the nodes were reloaded explicitly. The
      latter is not required at all.
      
      Resolves: #103185
      Releases: main, 12.4, 11.5
      Change-Id: I7a06852c6af...
      d627a4bb
  2. Mar 02, 2024
  3. Mar 01, 2024
  4. Feb 29, 2024
    • Christian Kuhn's avatar
      [BUGFIX] Honor workspace l10n_parent can point to live · bd02b4b6
      Christian Kuhn authored
      When a record localization is changed in workspaces,
      `transOrigPointerField` ("l10n_parent") can point to
      either the default language -live-, OR default language
      -workspace- record, depending on workspace action chains
      as detailed below.
      
      FormEngine did not deal with that properly when
      `showPossibleLocalizationRecords` for inline (or file)
      children is enabled, and did tend to show a possible
      localization child even though a record has been localized
      already ("shown twice"). This issue exists for a long
      time already, but became more obvious with #94623, which
      enabled `showPossibleLocalizationRecords` for tt_content
      image.
      
      The main fix of the patch is to make FormEngine aware
      of this scenario and suppress listing a localized
      workspace record as "can be synchronized" when its
      l10n_parent field points to live.
      
      As drive-by, the patch fixes a missing reference index update
      call in DH when "synchronizing" a relation in workspaces.
      
      The patch also adds some `@todo`s to point out situations
      where the "parent count" fields are incorrect.
      
      The added tests show scenarios where a localized workspace
      record points to either its live, or its workspace default
      language "parent" in the "l10n_parent" field. We're adding
      the tests for FAL, but the situation is similar with parent
      (here: tt_content), with inline csv and inline foreign field:
      
      a) modifyContentLocalizeAddDefaultLangRelationSynchronize()
         Having a content element and a localization in live. Add an
         image in workspace default language and synchronize into
         workspace localized record: l10n_parent of new localized
         sys_file_reference points to the workspace sys_file_reference
         record. This is quite obvious, since there is no live record
         to point to.
      
      b) localizeLiveModifyWsLocalizationAddLiveWsSync()
         Having a content element and a localization in live. Modify
         the localization in workspaces, by for instance changing the
         title of the content element. This creates a workspace
         overlay of that localized element in workspaces. Then add
         an image to the default language live content element, and
         synchronize this in the localized workspace element. Now,
         l10n_parent of the new localized sys_file_reference points
         to the live sys_file_reference record. This is because an
         overlay of the default language record does not exist.
      
      c) localizeLiveModifyWsDefaultLang()
         Having a content element with image and a localization in
         live. Modify the default content element in workspaces, by
         for instance changing the title of the content element. This
         creates workspace overlays of the default language record,
         *and* overlays of the localized content elements. It also
         creates overlays of the attached images in both the default
         language record and its localizations. l10n_parent of the
         sys_file_reference localized records now point to the live
         version. This scenario is debatable since overlays of the
         default language record exist. We decided to keep this
         behavior, since we'd otherwise have to deal with
         updating these pointers when publishing localizations.
      
      Change-Id: Iaab27586ff19cdc5f491324ca6dbc2cceff73373
      Resolves: #97548
      Resolves: #89858
      Related: #94623
      Releases: main, 12.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83165
      
      
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      bd02b4b6
    • Andreas Kienast's avatar
      [BUGFIX] Streamline `typo3-spinner-icon` element with SVG asset · 5e856cc6
      Andreas Kienast authored
      The Lit element `typo3-backend-spinner` uses a hard-coded SVG string,
      which has to be the same as the `spinner-circle` asset file.
      
      However, the SVG string was outdated as it neither respected the
      `currentColor`, nor respected the configured icon size. Both issues are
      fixed in this commit. Since `currentColor` is now taken into account,
      the variant styling has been removed.
      
      Resolves: #103198
      Releases: main, 12.4
      Change-Id: I24eababb8716076eb4db55a6bcd3eb43e98ea1fd
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/83164
      
      
      Tested-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Reviewed-by: default avatarAndreas Kienast <a.fernandez@scripting-base.de>
      5e856cc6
  5. Feb 28, 2024
  6. Feb 26, 2024
  7. Feb 25, 2024
  8. Feb 24, 2024
  9. Feb 23, 2024
  10. Feb 22, 2024
  11. Feb 21, 2024
  12. Feb 20, 2024
  13. Feb 19, 2024
  14. Feb 17, 2024