Page MenuHomePhabricator

[OTRS bug] "Sojourner (rover)" article shows text-on-text
Closed, ResolvedPublic

Description

From OTRS: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=11390663

Tested on 6.6, still occurring.

Article "Sojourner (rover)": desktop web (ok), mobile web (overlap), parsoid (ok), mobile-html (overlap)

image0.png (1×720 px, 3 MB)

Observations:

The problem is only visible for device/browser widths <= 720px.
The problem is also visible direclty in the template:
https://en.wikipedia.org/api/rest_v1/page/mobile-html/Template:Mars_map

Removing this rules from hacks.less fixes the problem here:

// Deal with Template:Multiple_image.  T38030 and T148505
.thumb .thumbinner {
  .flex-display( flex );
  justify-content: center;
  flex-wrap: wrap;
  align-content: flex-start;
  // avoid image child overflowing the container (T200518)
  // stylelint-disable-next-line declaration-block-no-redundant-longhand-properties
  flex-direction: column;

  > .thumbcaption {
    .flex( 1, 0, 100% );
    display: block;
  }
}

Turning off display: flex avoids this overlap as well.

Event Timeline

MattCleinman renamed this task from "Sojourner (rover)" article shows terribly to "Sojourner (rover)" article shows text-on-text.May 22 2020, 11:50 PM
MattCleinman updated the task description. (Show Details)
MattCleinman renamed this task from "Sojourner (rover)" article shows text-on-text to [OTRS bug] "Sojourner (rover)" article shows text-on-text.May 26 2020, 4:36 PM
bearND added subscribers: dcipoletti, bearND.

@dcipoletti I think this is an issue in MinervaNeue. If I added the wrong project please add the correct project.

Per T207618 this is not a browser we support. Feel free to reopen that ticket and debate there is if necessary.

bearND reopened this task as Open.EditedJun 5 2020, 10:23 PM

This also happens on Chrome and FF. All that is needed to reproduce is reduce your browser window width to < 721px and go to https://en.m.wikipedia.org/wiki/Sojourner_(rover)#Sojourner's_location_in_context.

Screen Shot 2020-06-05 at 4.25.18 PM.png (1×1 px, 2 MB)

@bearND it's the same bug as T207618 if this is about flexbox. Given T207618#5400133 we decided not to support browsers which don't support flex box. Please continue conversation on T207618.

If it's just about the overlap that's a template issue like most of these problems tend to be. I've fixed it on wiki for you: https://en.m.wikipedia.org/wiki/Special:MobileDiff/960968868?diffmode=source

@Jdlrobson Yes, this was about the overlap. Thanks for fixing this on-wiki.

It looks like this fix broke horizontal scrolling for the image map. The map area don't scroll with the image in smaller-width browsers. Since they are fixed it makes this image difficult to use/understand.

Is this another on-wiki change? Or somewhere else? While I don't understand web or wikitext as well as I understand mobile, I'm happy to make the change if someone can help orient me.

Screenshot 2.png (363×426 px, 279 KB)

Screenshot 3.png (362×428 px, 288 KB)

Content issues should be fixed on wiki yes.

Image maps in general are problematic on mobile and should be used as a last resort. Image maps require fixed widths and cannot be adapted to smaller displays.

This particular problem arises because of the width on the container being set to 620px - which is too big for a mobile screen. Ideally that element needs to be wrapped in a horizontally scrollable element with width: 100%. Hope this helps.

@Johan Seems like the template is broken. Can you comment on the talk page regarding that? Or are you comfortable with me doing so?

@MattCleinman I'm here if you need help, but always feel free to reach out and encourage small fixes like these on your own. I'm not here to insulate you from interacting with the community, I'm here to help you do it in a better way. (:

Thanks @Johan. I added something to the template's talk page.

TheDJ claimed this task.
TheDJ added a subscriber: TheDJ.

ok.. the original issue with text overlaying the other text, was actually because someone added a heigh limit which was insufficient for the contents... this has been fixed.

There's another issue, where the labels don't move with the scrollposition, this is because imagemap has a hardcoded noresize, which doesn't play well with the labels. But it's not as problematic.