Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-16155

Last Post links can be inaccessible in Hebrew/RTL language

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Invalid
    • Affects Version/s: 3.2.7, 3.2.8-RC1
    • Fix Version/s: None
    • Component/s: Styles
    • Labels:
    • Environment:
      Chrome 76.0.3809.100 or later

      Description

      Community issue report in https://www.phpbb.com/community/viewtopic.php?f=556&t=2522156

      An issue was noted with Hebrew (and presumably any RTL language) on Chrome 76.0.3809.100 or later. The links in the "last post" column of a row describing a forum or topic will be "inaccessible", meaning even though the HTML confirms there are correctly-defined links present, the user will be unable to click on or invoke those links.

      i.e. The user may be unable to click on some or all of the red-circled links shown in this screen shot:

      The Chrome 76 release notes (https://support.google.com/chrome/a/answer/7679408#76) describe the beginning of a change-over to LayoutNG (https://developers.google.com/web/updates/2019/06/layoutNG), which acknowledges potential new behavior, but intended to address issues even specifically in RTL scenarios.

       

      The purpose of this bug is to have someone experienced in the RTL design and intentions of phpBB prosilver to review this scenario, and conclude whether Chrome 76 / LayoutNG has helpfully improved something we now need to take into account.  Versus whether Chrome 76 has simply broken something, but which we still might want to take into account given Chrome's market share.  Versus whether the involved elements maybe just didn't need to use the "now problematic" attributes to begin with, thereby side-stepping the question.

       

      In Edge as well as pre-Chrome 76, the "margin-left:-440px, margin-left:440px" arrangement between the row-item's <dt> element and list-inner <div> in the RTL case results in the list-inner <div> margin heading out-of-bounds to the RIGHT side of the containing row-item, as pictured here:

      In Chrome 76.0.3809.100 or later, what we see is that this same "margin-left:-440px, margin-left:440px" arrangement between the row-item's <dt> element and list-inner <div> in the RTL case results in the list-inner <div> margin heading extending out of the LEFT side of the containing row-item, as pictured here:

      This causes the links and other content of the dd.lastpost column to be considered "covered" by the list-inner <div>, and makes the links "inaccessible".

      Note the actual experience of this issue can be variable even when using Chrome 76, because the height of the list-inner <div> can vary. So the list-inner <div> may or may not "cover" the entire content of the dd.lastpost column.  Any links able to "peek out from underneath" the overlap can still be accessed.

       

      An additional observation:

      After implementing a workaround of applying "position: relative" to the dd.lastpost column in the RTL case, the absolute positioning being applied to the ul.topiclist <dfn> (margin-left:-999px, width:990px) caused the otherwise invisible <dfn> element to now overlap the list-inner <div>. Which then "covered" any links affected by that overlap. So "display: none" for the <dfn> element was added to the workaround.

      Originally I thought the absolute positioning involved in the <dfn> element might be a pre-existing RTL issue, just unexpectedly exposed when implementing the workaround. But after continued observation, it seems like I'm probably wrong on that; not withstanding the addressing the <dfn> overlap is still a required part of the workaround.

        Attachments

        1. chrome.png
          chrome.png
          28 kB
        2. dfn.png
          dfn.png
          28 kB
        3. edge.png
          edge.png
          26 kB
        4. links.png
          links.png
          24 kB

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              EA117 EA117
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: