Getting some CORS errors. E.g. https://www.gnome.org/ fails to load fontawesome icons. And there's an interesting bug where opening mobile menu loads a page.
Oh CORS… we’re still figuring out an approach on how to handle static assets that have restrictions. Sorry about that, but I assure it’s one of the top things we are going to address.
I am getting a "Mobile version not available" modal that wont go away on its own on desktop. I can trick it by making my browser full screen, refreshing, then resizing it back to a half sized window.
Ahh bug related to how we detect mobile. Would ya mind reaching out at hello@viewport-tester.com so I can get a few more details on this?
That’s not a bug. Thats a feature. When I request desktop view in my iphone, it should just treat me as a desktop user. I know its buggy. I know its a horrible experience but I just wanna see what its like.
Now I wont even check it out because I didnt get that first impression on my phone. I will just forget it.
Just my 2c
Really sorry to hear your first impression wasn't great @altdataseller It has to do with limitations around performance/memory. In some instances, loading large documents in multiple iframes at the same time could cause mobile safari to crash. We have plans on how to address this, but we thought that seeing as frontend responsive testing is most likely going to be done on a Desktop-like device, we would prevent possibly crashing your mobile browser and show you a video walkthrough of how it works on desktop. Happy to chat more about this offline if you want: hello@viewport-tester.com
This should be fixed now.
Nice, that seems to be fixed now. Thanks!
I noticed another possible bug. When trying it out on your website, it reports an "Invalid URL" error.
Can you share the URL you're testing?
Yep!
The detailed text on the modal says: We can only load URLs that pass standard pattern checks.
Haha funny! Yeh we disabled that, in part, because it can result in an infinite loop.
Hahahahahaha, ahhh that makes sense. I didn't think about it getting suck in a loop.
:)
Mobile Safari set to "always show desktop version" still triggers this modal.
Edit: even if you click "Request mobile version", the modal is there
Unfortunately we don't have support for mobile Safari yet. It has to do with some performance challenges related to drawing multiple iframes to the page. Hope to get that fixed soon.
Thank you for creating this! Impressed by multi-devices at once. Looking forward to seeing how this evolves!
Thanks @Dev_Olly! Feel free to leave a comment if you run into any issues!
Something doesnt seem right. This website loads fine on Chrome's inspector design previews, but looks broken here:
https://viewport-tester.com/?url=https%3A%2F%2Fespncricinfo....
Great find! I'll create an issue for this one. I'm guessing it's related to the media queries that are taking place (or possibly, JS). Will track this one and comment on your reply again once it's fixed.
Targeting specific viewports is such a wrong way to go about it. Just resize your browser (or use the built in responsive design preview and freely resize that) to see if you reflow in a sane way. A single drag gets you hundreds if not thousands of different widths and aspect ratios tested.
Thanks for the comment @account42 Agreed that a really-great responsive site is one where specific viewport dimensions don't matter. One thing we've run into (and want to test for) is users mentioning they're using a specific device and having issues.
In those cases, it's helpful for us to really quickly choose from a list the device, and view the site. That way, we don't need to know the exact dimensions of the device, and can also test a possible fix for that device against other viewports.
Are the viewports sized with or without browser chrome, like the address bar and bottom bar?
Great question! Right now, it doesn't take into consideration the browser or device address/bottom bars. We documented that here: https://github.com/bitcomplete/labs-delta-viewport-tester-vi... (Caveat #1).
We plan to address this in the future, but at the moment, Viewport Tester works in a similar way to Chrome's native Device Inspector: it resizes the viewport to the exact dimensions.
If I could toggle between different states of the top/bottom bars I would use this tool every day.
Interesting: can you elaborate on this? Would love to better understand it, so we can consider adding this.
I am not the person who originally asked for this, but I’d want to scan my eyes over conditions:
* with and without the keyboard focused,
* in each of the preference states (e.g. tab bar vs single tab for iOS, which influences whether there’s a compact address/button bar on the bottom or an address bar at top plus a button bar at bottom), and
* both of those in portrait and landscape
Thanks for this @alwa. It definitely helped me better understand the question. I commented below @doctorpangloss but agreed: portrait/landscape mode are vital, and that's already on our roadmap.
This is like that scene in Star Wars where Luke asks questions and Yoda just closes his eyes, fades away and dies.
This is meant as a light hearted question: how could you have gotten this far making a viewport tester and the mobile website development journey without understanding and dealing with the most important and disruptive behavior in mobile viewports? Like I get that this is just a free project and it does what it does.
Haha funny analogy. What you and @alwa said makes sense: thanks for sharing that. It's related to Caveat #1 I mentioned above, but I like the idea of being able to toggle on/off the header/footer, to simulate real-world scrolling behaviour. I got that added to our list.
After clicking on four screen sizes.
> To continue enjoying full, unrestricted use, please sign up for updates.
I don't want to give you my email. Why are you forcing me to?
Whoops! That was only meant to stay in there for an unrelated feature. Removed :)
Thanks. Very useful app.
Thanks! Let me know if you have any feedback :)
This reminded me of a very similar one but for the desktop from a few years back. Here you go;
Source at https://github.com/responsively-org/responsively-app
Thanks for sharing this @Brajeshwar! This is a great tool and one we played with. One primary motivation for us, that caused us to build a web-based Responsive UI testing tool, was we wanted to be able to easily share issues/links with our team. It has it's limitations, but there's something super-handy about being able to test a URL, find an issue, and then link directly to that experience on Slack, Linear, Jira, etc.
shot-scraper is a CLI tool for HTML render snapshots with --height --width and --scale-factor (--retina ~= --scale-factor=2.0) args, and a -j/--javascript option to run JS before taking the screenshot.
There's not yet a way to resize the viewport and take another screenshot without loading the page again.
There's not yet a way to store (h,w,scale,showbrowserchrome) configurations in a YAML file; but shot-scraper does work in GitHub Actions.
Some web testing tools can record a video of a test session and save it if there's a test failure.
E.g. Playwright defaults to an 800x600 viewport for test videos to retain-on-failure or record only if on-first-retry: https://playwright.dev/docs/videos
Something like Cloudflare Browser Isolation - which splits the browser at an interface such that a Chrome browser server runs on a remote server and a Chrome client runs locally - might make it easier to compress recordings of n x test invocations (in isolated browsers or workers)
This is awesome: thanks for these resources! We'll take a look at Cloudflare Browser Isolation for sure. We've played with screenshot tools at specific viewport dimensions etc, but it's not often the right fit for when we're doing interactive frontend responsive updates. That aside though, the screenshot APIs could be a great integration to be able to download/save screenshots of specific viewports.
DevTools has a list of default viewport sizes, but they change from browser release to release. Is there a better way or an existing [YAML] file schema to generate a list of viewport configurations to import into DevTools?
We looked into this, and we couldn't find a way to do so, but we've open sourced the data (here: https://github.com/bitcomplete/labs-delta-viewport-tester-vi...) so if you are able to find a way to do so, that could be a great option.
This is brilliant. Thanks for building it.
Thanks! If you run into any issues or have any ideas, please share :)
could this be a replacement for emailonacid's device viewport preview feature?
This absolutely could work with HTML emails. One challenge with Email On Acid's is you do need to have an account with them, and it is limited to emails. We find most of our viewport testing is related to landing pages, etc.
Pretty cool stuff!
Thanks @kmfsousa! Feel free to leave another comment if you have any ideas, or run into any issues :)
"Mobile version not available" popup that cannot be closed is such an irony. Next time, test your website with a viewport tester :)
@ivanjermakov I know: it's a bummer that it doesn't work on mobile. We initially _did_ make it work (and responsive), but we ran into performance/memory issues. This is related to how much memory can be allocated on mobile devices, and since we open multiple iframes, it caused a lot of problems.
We have a specific plan on making this work on mobile, but for this initial version, we decided that making it limited to Desktop was okay (since, realistically, people who are doing frontend responsive testing, are most likely doing it on a wider display).