# Description of problem: When a Youtube page is opened through right click option "open link in a new tab" *AND* the user do not wait for the page to load *before* changing to that tab, WebKitGtk (frequently) renders that page/tab with a wrong layout. # Version-Release number of selected component (if applicable): epiphany-1:3.16.2-2.fc22.x86_64 webkitgtk4-2.8.3-2.fc22.x86_64 #Steps to Reproduce: 1. Open "https://www.youtube.com/". 2. Right click on any video link then choose "open link in a new tab". 3. Change to that new tab *imediately*. # Actual results: Page renderized with a wrong layout. # Expected results: Correct layout. # Additional info: Not happens 100% of time; if rendered correctly, please, close the tab and try again at least a couple of times. Something, sometimes, trigger the correct rendering but I don't know what.
Created attachment 1049677 [details] Screencast of the bug.
I can reproduce this 100% using Open Link in New Tab, regardless of whether switch to the tab immediately. Maybe it is an Epiphany bug; not sure.
OK this is interesting, if you resize the window a bit, YouTube will switch to using the correct layout.
Created attachment 1049919 [details] New screencast showing a likely "trigger". Probably our "test method" was slightly different. Seems, now, like it happens before the "playing arrow" appears in the title of the page. And not after. Maybe Web gives, initially, wrong viewport dimensions to WKG, when loading on the background? (or gives nothing at all, and WKG uses its "defaults"). And, then, the resize triggers a recalculation of the layout, now using the right dimensions? Also note that in *both* cases of background loading the page is rendered wrongly, but, in the "after the arrow" case, something (the tab switch itself?) triggers a layout recalculation (like the resize action?).
(In reply to Diogo Campos from comment #4) > Probably our "test method" was slightly different. > Seems, now, like it happens before the "playing arrow" appears in the title > of the page. And not after. TBH I have never been able to get a YouTube video to play in Epiphany (probably you installed H.264 codecs from RPMFusion?) so that would explain the difference. > Maybe Web gives, initially, wrong viewport dimensions to WKG, when loading > on the background? (or gives nothing at all, and WKG uses its "defaults"). > And, then, the resize triggers a recalculation of the layout, now using the > right dimensions? Something like that, though I think it's slightly more likely that the bug is in WebKit. (Or YouTube. I have no clue.)
> TBH I have never been able to get a YouTube video to play in Epiphany > (probably you installed H.264 codecs from RPMFusion?) so that would explain > the difference. Yes. "gstreamer1-libav". > Something like that, though I think it's slightly more likely that the bug > is in WebKit. (Or YouTube. I have no clue.) I could swear that I've seen strange renderings on other websites, too. I will try to document similar cases here, from now on, if found.
I think this is the same bug I see reading articles on vox.com. Images render very blurry when opened in new tabs (which I never noticed until now!) but are always fine when the page is refreshed. I think we are reporting a bogus window size. So Vox thinks "this user has a very small browser window, we can send low quality images since he won't see the difference," and YouTube thinks "this user has a very small browser window, we'd better adjust our layout accordingly."
Yup, test with http://whatsmy.browsersize.com/ Open it in the current tab -> it's fine Open it in a new tab -> we claim our width is 0 pixels Refresh it after opening in a new tab -> it becomes fine
This will be fixed in Fedora 23. I'm not sure if it will be fixed in Fedora 22 since it's not straightforward to backport, but there's a decent chance it will show up in 2.8.5.
Don't worry. We all know it's a bunch of work. Besides, it's not even a security/critical bug.