@Jdlrobson can you take a look at this when you have a second? I'd love to move it up in the queue if it doesn't seem to complicated

@alexhollender added some thoughts. Seems a bit of risk here. Answer the questions and throw it into needs analysis in the backlog so it enters the developer queue :)

@Jdlrobson just put answers to your questions in a Design notes section

Let's attempt to estimate this with the other developers and see what comes back.

It's also a little tricky to select the text since the cursor isn't as an I-beam.

@Niedzielski ah that's a good point. I guess in this case clicking is more common than selecting text. Maybe we can't have our cake and eat it too? Will try to think of a solution here, let me know if you've got any ideas.

this is on @alexhollender

@Jdlrobson I think this is good to go? Design notes in the description describe what the UX should be.

@alexhollender it's not clear how this impacts accessibility and which option to go with.
In particular, it's not clear whether the area around the settings cog is clickable or not.
I think what would help is a red polygon detailing the clickable region (similar to developer notes but showing what we'd like to get to). Can that be arranged?

@Jdlrobson let me know if this clarifies. Regarding accessibility: I did speak to Volker about this. No conclusion thus far, but I think we can keep that a separate topic (tracked here T195718).

The footer element is blocking the lower part of the popup. Is there any reason this can't be fixed just by fiddling with the CSS so that its width doesn't stretch across the whole element, and repositioning things so that this doesn't affect the appearance?

Change 442880 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/Popups@master] Whole popup area should be clickable

https://gerrit.wikimedia.org/r/442880

Change 442880 merged by Jdlrobson:
[mediawiki/extensions/Popups@master] Whole popup area should be clickable

https://gerrit.wikimedia.org/r/442880

Tested this quite a bit yesterday. Looks good to me on staging. Tested on Windows and Mac and Chrome, Firefox, Safari, IE and Edge.

In T192773#4495517, @Jdlrobson wrote:

Marking as low for the time being. Correct me if I'm wrong!

Sounds good to me.

@Jdlrobson @ovasileva why low priority? Thinking that since page previews are front & center this bug is pretty visible

Patch has been reverted. We'll need to rethink the approach here at a later date.

What ended up happening with this patch?

How would y'all feel about bringing it onto the sprint board? I feel like the priority should be higher than low.

@alexhollender not sure I understand. The original fix here caused T200940 so we reverted it. We don't currently know a way to fix this without a big risky rewrite of the page previews render code.

We'd need to schedule some analysis (spike?) if we want to pursue a solution to this problem.
My preference is to wait till we have less projects in flight to do that.

In T192773#4616067, @Jdlrobson wrote:

@alexhollender not sure I understand. The original fix here caused T200940 so we reverted it. We don't currently know a way to fix this without a big risky rewrite of the page previews render code.
We'd need to schedule some analysis (spike?) if we want to pursue a solution to this problem.
My preference is to wait till we have less projects in flight to do that.

+ 1 on this. We'd want to fix this eventually but as it seems fairly complex and we have higher-priority project in-flight, I'd wait and reconsider a bit further down the line. We can bump up the priority then.