This looks like Page-Previews to me, not like that gadget.

Cannot reproduce the problem with 120% zoom level and 960px window width in Firefox 63.

@ovasileva can get something similar with Safari but only with a narrow browser window and fully zoomed. I'm not sure of the validity of that setup in terms of expecting the preview to be fully onscreen.

got it! I didn't notice the width of the screen in the original report. This seems acceptable to me as well. @alexhollender - any thoughts from your side?

@ovasileva I'm fine with us not supporting fully functional page previews at this browser width. Oddly enough there is enough room to display the preview though, so I wonder if there's something relatively straightforward we can tweak in the display logic that avoids this?

@alexhollender I have two possible solutions for you - 1 big, 1 small. Let me know your thoughts on this.

@Jdlrobson my inclination is still that this isn't worth fixing. Is there something new that I'm missing? It seems like it would happen quite rarely, plus at that screen width the site doesn't do great in general, so I'm not sure it's worth fixing page previews (of all things). Disabling the entire feature seems like overkill, as you can still use it and get value from it in many (maybe even most) cases.

I think it's understandable to not fix this. I think if we do anything, I think it would be the trivial tax of disabling page previews on a low threshold.. that seems sensible regardless given users might be using Minerva's desktop version on a mobile screen but there is no pressing need to do this now.

Ok cool. Moving out of this column.

What should we do about this one @ovasileva ? See T210873#4998319

I like the idea of disabling at very narrow widths - I suppose the next step would be to set a threshold. @alexhollender - any thoughts on what that number could be?

some notes:

• the widest a page preview can be is 450px (horizontal previews)
• page previews are not positioned in a vertically centered way relative to the link, rather they are offset to the right or the left
• the pokey is about 28px in from the edge of the horizontal preview, meaning about 420px of the horizontal preview gets rendered offset to the right or left of where your cursor/the link is...so for a word that's directly in the middle of the screen you need about 420px of space on either side of the word to ensure that the preview won't get cut off
• therefore we should start seeing this issue appearing on horizontal page previews at around 840px wide screens (i.e. 240px * 2), which is indeed what I found. here is my screen at 840px wide, hovering over the link "bedrock" in the center of the screen:

it's a little hard to tell from the screenshot, but a few pixels on the right of the page preview are being clipped off

so one solution would be to allow previews to position themselves in a more centered way, rather than being offset to the right or left. taking the same preview and screen width from the scenario above you could imagine us doing this instead:

if we did this i believe we wouldn't get this issue until the screen width was below 450px. however I imagine that we are rendering the previews in an offset way for a reason. one guess would be we do this so that the text in the preview lines up, more or less, with the link text (in as many cases as possible), so that your eye doesn't have to move very far when transitioning from reading the article to reading the preview. compare the eye movement necessary for the version on the left (minimal), versus the version on the right:

(we do, however, render plenty of previews in a way such that the text of the preview does not align with the link text., it happens often when the link is near the edge of the screen..I'm just assuming this isn't ideal).

so we could consider the tradeoff: page previews not getting clipped at smaller widths vs. the worse reading experience of having to move your eye further between the link text and the preview text

a perhaps more simple solution would be to drop images from horizontal previews at smaller widths. if we did this the widest a preview could be would be 320px, minus the 28px offset, meaning the problem wouldn't start happening until screen widths of 584px (320px - 28px = 292px * 2 = 584px), at which point we could either hide previews altogether, or just be okay with some of them being clipped off.

@Jdlrobson @ovasileva what do you think about those two possible solutions?