We are trying to set up screenshot tests to automate UI/ layout regression testing by comparing screenshots against an expected set of screenshots. We are using testcafé for that but we are struggling when scrollbars come into play for full-page fixed width screenshots:
const testcafe: TestController;
await testcafe
.resizeWindow(1024, 768)
.takeScreenshot({
fullPage: true
});
This will result in a screenshot with a width of 1003px (not 1024px!) and a height of 1546px. Nonetheless, the screenshot still contains the vertical scrollbar which is surely not out of coincidence 21px wide. It's neither full page as few pixels are also missing at the bottom of the page which most likely does actually result in the vertical scrollbar.
When trying to workaround the reduced width by adding additional pixels (21 to be exact), the screenshot is indeed 1024px wide and has a slightly reduced height of 1510px (as something on the page is not required to be wrapped anymore). It's still missing parts at the bottom of the screenshot and it still has a scrollbar.
const testcafe: TestController;
await testcafe
.resizeWindow(1024+21, 768)
.takeScreenshot({
fullPage: true
});
Now it gets slightly more weird: The behavior just described continues up to a width of 1024+21+20 px. Screenshots have a width of (1024-21) +21+20 px, a height of 1510px and scrollbar. Starting from 1024+2*21 though the vertical scrollbar disappears, the screenshot is complete also at the bottom with 1510px as the correct height (as again something else on the page doesn't have to wrap anymore) - but unfortunately I do have a screenshot with a width of 1045px which is not of the intended width of 1024px.
If I specify resizeWindow with a width of 1024px I do expect a screenshot exactly of that width if it does include a scrollbar. If testcafe thinks it has to take the screenshot without the scrollbar and reduce the screenshot to a width of 1003px it's also fine with me - but here I guess it has somehow considered the scrollbar but still not actually cut it off.
The same mechanism for a page which content doesn't require the height of 768px, in other words doesn't have a scrollbar to begin with, the screenshot has a width of 1024px without any "correction".
Few versions if relevant:
node: v14.16.0
testcafe: 1.10.1
browser: Chrome 89.0.4389.72 running on Windows 10
Do you have any further ideas?
Related
Please have a look at this snack:
https://snack.expo.io/#yolpsoftware/groaning-nachos
When you run it in web (separate window) and then resize the window a bit, you'll notice some strange behavior:
This might have been an error in Expo Snack. When I reloaded the window, the behavior disappeared. So the following is not relevant anymore: When the window is big enough for the two videos to fit in, their parents get a height of 0, so they are rendered on top of each other. As soon as you make the window smaller, this behavior disappears.
Even though both the <Video> and their direct parents have width: 100% and aspectRatio: 1.333, the height of the <Video> elements always stays the same. The aspectRatio prop is not respected.
Why is that so?
I want the video elements to fill the width of their parent, but their height should be set according to the aspectRatio prop.
I'm using Font-awesome in my project, and every icon is aligned in the middle of the line. On Chrome, Firefox and IE, They are aligned corretly, but on Safari, the icon drop around 3 or 4 pixels.
I inspect the icon and in every browser, they are render and ocupate the exactly space they should be. But in Safari, they are rendered with extra top size, a transparent padding on top of the icon. It's not vertical-alignment or line-height problem, the character itself have this "transparent padding" on top.
That seens silly, but on a huge project, every icon is aligned 3/4px down than it should be give me a lot of headache.
One possible reason is that you have a different default line height in the different browsers. Try explicitly setting this to see if if it makes a difference:
CSS
i{
line-height:20px;
}
or even
i{
display:inline-block;
}
depending on the specifics of your styling, you might need to also set a class on the i tag, e.g.
i.icon-class{ ....}
Good luck!
I am trying to load external webpages into a webview that is smaller than the device. This is an example:
var window = Titanium.UI.createWindow();
var webview = Titanium.UI.createWebView();
webview.setWidth(320)
webview.setUrl('http://www.bostonglobe.com')
Ti.API.info('webview width = ' + webview.width);
window.add(webview);
window.open();
You can see the webview scrolls horizontally, acting like a its the same width of the device, not 320 as specified.
Any help to make this work would be appreciated.
This is actually very easy to do and is built in to Titanium for all platforms. Just use the scalesPageToFit property of the WebView, this has been around since Titanium version 0.8 so its quite stable.
var self = Ti.UI.createView({
backgroundColor : '#ff0000'
});
var webView = Ti.UI.createWebView({
url : 'http://whatsmy.browsersize.com',
scalesPageToFit : true,
width : 280
});
self.add(webView);
Note the platform difference though:
"On iOS, setting this to true sets the initial zoom level to show the entire page, and enables the user to zoom the web view in and out. Setting this to false prevents the user from zooming the web view."
"On Android, only controls the initial zoom level."
Also note that their is a difference between pixels, and points, as every screen has different pixel density. Here is a screenshot showing this works, note the surrounding red background:
Thise screenshot was taken from a vanilla project using the "Default Window" template from Titanium Studio. All I did was replace the "ui/common/FirstView.js" file with this gist.
It is possible if you make your WebView very small that it wont show the content (as many websites specify a minimum zoom scale) so in that instance I would suggest using a transform like this:
var webView = Ti.UI.createWebView({
url : 'http://whatsmy.browsersize.com',
scalesPageToFit : true,
width : 280,
transform : Ti.UI.create2DMatrix().scale(0.5, 0.5)
});
All this does is take the previous view and half-size it.
Of course, you will have to calculate your own uniform scaling factor, but that should be straightforward depending on your requirements and platform target. Here is a screenshot of the scaled result.
Using a combination of these methods you definitely have the tools needed to solve this problem. Good luck!
try doing it this way instead and see if you get better results:
var webview = Titanium.UI.createWebView({
width:320,
url:'http://bostonglobe.com'
});
Another point to consider is that the page you're loading probably isn't mobile friendly. Apple's web view control is deciding to show it at a scaled rate to make it fit. In the case of whatsmy.browsersize.com, it's telling you the scaled size of the web page, not the control size of the web view.
You most likely want to change the width and initial scale of the web page's viewport.
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=3.0;" />
EDIT: For third party sites, after the page loads, you can force it to scale via JavaScript. If you don't want to see the initial unscaled page, hide the web view until has scaled down.
webView.evalJS('document.body.style.zoom = 1.5;');
Is this an Opera bug? Please compare this jsfiddle jsfiddle.net/n5hBf/1 with this one jsfiddle.net/n5hBf/2 You should see the difference in the height. Those two jsfiddles are the same except in the first one I set styles in one statement and in the second jsfiddle I set them one after the other. That works well in other browsers but not in Opera, so you'll definitely need the latest Opera to see what I am talking about.
EDIT:
Well, now I think it is not actually a bug but rather the way how word-wrapping is handled by Opera. It differs from how it works in other browsers such as FF, Chrome, and IE. If you add word-wrap: break-word; to the textarea element, you'll see what I mean: http://jsfiddle.net/n5hBf/5/
EDIT 2:
Problem:
Say, if we have a textarea element that is 100x100 in size and contains too much text to be fit inside the textarea element, the text will overflow, thus enabling the scrollbar(s) to appear.
Goal:
In the two jsfiddles, I was trying to expand the textarea element to the size that is large enough to accommodate the content without the need in scrollbars.
Wrong solution:
The first jsfiddle behaved badly in Opera because it expanded the height too much than needed. The second jsfiddle worked well in Opera (meaning that it changed its size to the actual dimensions needed for the content; not much, not less), though the result in Opera differed from what I could observe in the other browsers. In the other browsers, only the height got changed. The result was wider in Opera as it changed both width and height.
Understanding:
As I figured out, by default Opera doesn't break long words into lines but instead it adds a horizontal scrollbar. While the other browsers do break them into lines. Also, browsers render it so that the scrolling is added only for the sake of those long words while the rest of the content occupies the same width... And then I got the clue!
Right solution:
I understood that the actual dimensions of the content were defined according to the initial textarea's size, so one of the dimensions turned out to be invalid once we changed the other one. That is, if we change the width the height is no longer actual because the content spreads over the new width making itself shorter in height. That explains why the second jsfiddle worked as intended: firstly I got the new width and applied it, then the content occupied the new dimensions, and only after that I got the new height and applied it. So, if we need to change both width and height, we need to firstly change the width and only then change the height. In browsers other than Opera it was only needed to change one dimension, so there was no difference whether the styles were changed in one statement like in the first jsfiddle or they were changed in two statements like in the second jsfiddle.
The only reason it breaks in Opera is because it's the only browser that doesn't use word-wrap: break-word by default on textareas. So it's not a bug, simply a result of a different default style.
If you add word-wrap: normal to the textarea CSS in your fiddle it will break in the same way in the other browsers (except in IE, where it breaks in a different way).
Without word-wrap: break-word, the width is different from the scrollWidth, which means that changing it will affect the scrollHeight.
However, by doing this
$textarea.css({
width: $textarea[0].scrollWidth,
height: $textarea[0].scrollHeight
});
both the scrollWidth and scrollHeight are evaluated first before they are actually set. That means that that change in the scrollHeight which would be caused by changing the width is not taken into account.
Setting the width and height in separate .css() statements one after the other will mean the scrollHeight will have been updated before it is set.
I try to setup UltraMon with a really big width and height for my Safari on Windows.
See capture : http://cl.ly/de21e9cd2cf4f265efc4
The problem is that the width and height seems to have a max value that I would like to change.
I want UltraMon not to change my width and height, even if they are bigger than the screen resolution.
Windows doesn't allow that, according to the developers of UltraMon.
See http://www.realtimesoft.com/multimon/forum/messages.asp?tmpl=UltraMon&Topic=10795#39510