Develop Reference

Changing height of element moves element outside of viewport when page is scrolled

We got a list of cards that show a small part of a textbox. That textbox is limited in height via CSS. When a user clicks on "Details" the textboxes height is changed via javascript to the real height of the content.
The problem is, that when the viewport / window is scrolled and the cards height increases, it pushes itself out of the viewport. When the window is not scrolled at all, it works.
Please see the following video: https://monosnap.com/file/HauaJrJlkx2MBLGt3QOa5ulJMxFTnv
0:00 -> 0:08 is the desired opening / closing behavior that I want
0:09 -> 0:16 is the behavior I do not want, as the top text is moved out of the viewport.
Is there a way to keep the viewport, preferably without JS?
Edit: This happens only in Chrome (84.0.41), in Firefox and Safari it works as expected.
I can send you a link to the staging environment if necessary, please contact me via info#felixhagspiel.de

Looks it's done more logical that you want to be. As control placed in a bottom element (bad UI) better keep this control in viewport (strange that chest Crome thinks so).
So just display:flex build all this magic :)
Please look examples
https://drive.google.com/file/d/1faTDwJBQEv-V96O8-HC-8R2_hXkGzsQJ/view?usp=sharing
UPDATE: also please remove
tabindex="0"
And use button instead div to get the same logic with the keyboard navigation.
On Video last Chrome
Google Chrome is up to date
Version 84.0.4147.89 (Official Build) (64-bit)

screen.width produce different result on Firefox and Chrome

I was working a with a site and I had know the width of the screen that's why I tried with screen.width but I don't know why I'm getting different result on Firefox and Chrome. Seems Firefox showing me the correct value but Chrome doesn't.
Is there is anyone who can assist me to know whats the reason?
Thanks

The reason is that there is no current standard that defines what the value should be. The closest is the CSSOM View Module, which states that:
The width attribute must return the width of the output device, in CSS pixels.
However, that specification is a Working Draft, which means it is a work in progress and the definition stated may not be what is implemented. Indeed, the Editor's Draft gives two different definitions:
The Web-exposed screen area is one of the following:
The area of the output device, in CSS pixels.
The area of the viewport, in CSS pixels.
So obviously, browser vendors are taking whichever definition they want.
For more discussion on that property, see PPK's rant "screen.width is useless" on Quirks Mode

Detect if the viewport width is bigger than the visible width on Mobile Safari using javascript

I have an element with position fixed (pinned to any corner) on a page (which I do not necessarily have control over the meta viewport tag - it is an embedded widget for third party sites). On Mobile Safari when the user pinch zooms the page at a certain point the viewport becomes larger than the visible area. At that point the fixed position element stays attached to the viewport and is not necessarily in the visible area.
I would like to compare two widths: the width of the visible area and the width of the viewport. I believe the size of the visible area is window.innerWidth. I am not sure how to measure the viewport.
I have been trying to see the relationships between:
document.documentElement.clientWidth
screen.width
window.innerWidth
window.outerWidth
...But have not been able to see anything obvious.

This is butt ugly but it does show some code that almost works (view on iOS to see it working. Use a desktop and click edit at top right of page to see or edit code):
https://jsbin.com/jopamu (iOS only)
The trick with the "overzoom" calculation is nasty but it does compensate somewhat for the multiple viewport zooms. It is a complex problem to solve because there are competing issues:
pinch-zoom
zoom due to input focus
the "position:fixed" zoom
potentially the OS (accessibility) zoom
The possible solutions I have found are:
Position the menu using the calculations above and position:absolute - updating the left/top in onscroll event. Has ugly juddering (can improve a little by hiding and only showing when zooming/scrolling finishes).
Position the menu using position:fixed but change the left/top to correct the menu position as zooming/scrolling occurs. Much less judder but I couldn't quite get it 100% reliable (some race condition).
Not suitable for your case (and highly unrecommended due to risk of breaking things): you can prevent pinch zooming and iOS10 double-click zooming by cancelling default on touchstart. Difficult because it needs many other workarounds so normal touch works, and needs synthetic scrolling and zooming (but has ugly side effects such as preventing scrolling working sometimes and also interferes with accessability e.g. if voice accessability turned on etc etc).
If you just want to see the widths then use the older version:https://output.jsbin.com/jopamu/6

Rendering bug in WebKit browsers

In the project I currently work on we experience very strange rendering issue. The worst thing is that this issue emerges completely spontaneously and after several days of testing we haven't managed to find the sequence of actions wich would reproduce this issue. Here is an explanation of how this bug look like. Here is a screenshot of how the page should look like:
But instead of this after some manipulations content block pops up so only the part of the content is visible and its look like:
The most strange thing is that such a position of the block is not based on values of CSS properties as shown by Web Inspector.
As you can see the CSS properties are ok, while the position of the block is not. This fact suggest me that it could be some rendering bug of the WebKit engine
The project is built using Ext JS 3.4 and it is a classical one-page web application. This issue was seen in the last versions of Chrome and Safari on Mac OS 10.7/10.8. Though due to the spontaneous nature of this issue it might be present in other browsers and platforms too.
Any piece of advice on how to debug such issues or how it could arise is welcome.

Please check if any of your code or Ext JS's code is using scrollIntoView method, we have seen similar issue when scrollIntoView is called on any element that does not have overflow set to auto and it is inside an clipped element that is probably placed relatively positioned.
It seems bug in webkit because it scrolls clipped element which is not happening in other browsers.
I also see two elements in same hierarchy which has overflow set to auto. And scrollIntoView is scrolling wrong element.

Chrome and safari on Mac are having problems with scrolling. If the element has been scrolled and the content changes, the scroll position is kept even if the content is not high enough to require a scrolling.
The work around we have found in our application is to resize the container (the one that has the scroll) so that it has the scrollbar (or else you cannot play with the scrolling properties) and then reset the scrolling, and the height.
$(container).css('height',1).scrollTop('1').css('height','');
Here is how we do it in jQuery. You will not even see a flickering :)
I am not sure if it is the problem, but this thing kept us on our feet for a while.

i went through the same problem while working with a sencha touch 2 app and because thats same as ExtJS i have a solution for you
this probably is a bug in the framework and this happens when the ExtJS renders the application before the browser populates mayb the correct window.innerWidth and window.innerHeight and thus the viewport cannot take the correct width and height. this also explains the randomness of the event. This becomes more prominent when used on mobiles probably because of the limited resources and slow response.
the solution that i took to handle this mayb isnt a good one but i couldnt find a better one considering is a glitch in the framework itself
i poll for the correct height and width of the browser for around a sec after every say 100ms for the correct height and width of the window and if i find that the height OR width of the viewport isnt same i re adjust it. because you are working with ExtJS and app would run on high powered systems(as compared to mobile phones) i would recommend a smaller interval and then to be safe a larger time period to which it polls.
heres the code that i use currently edit according to your needs
var aId = setInterval(function () {
if (Ext.Viewport.getWidth() !== window.innerWidth || Ext.Viewport.getHeight() !== window.innerHeight) {
Ext.Viewport.setSize(window.innerWidth, window.innerHeight);
clearInterval(aId);
}
num = num + 1;
if (num > 10) {
clearInterval(aId);
}
}, 100)
i currently use this code inside the launch function of the app. but you can also use this inside the show event of the viewport for which you should keep the interval time to minimum possible to avoid any lags.
with this if you think this app might be used on devices where the window height and width would be changed by the user (like that of mobile browser when the orientation changes or if you think user would change the height and width of the browser window). then just copy & paste the same code piece inside the viewports resize event so that it also polls and resizes viewport when the size of the viewport changes.

Did you try adding a clear:both; block after the toolbar div ?
<div style="clear:both;"></div>

#bjornd it's pretty hard to debug without any code :)
Is the toolbar positioned and has the content an ID that's called in the URL?
In other words: is there some link (e.g.) that triggers #content and has no preventDefault() etc? This would scroll the page probably.
I dunno, this was the first thing that came to mind.
It could also be the toolbar content that is (for some reason) no longer cleared or some change in the content's top position (relative to another changed/removed element?)
Try and create a stripped-down test-case that contains the simplest of code but still triggers the bug. If you post that (through e.g. a Fiddle etc) we can have a proper look.

It might be a css issue;
I've had a similar issue using equal height divs by setting a padding-bottom: 99999px; and margin-bottom: -99999px;. Which workes fine in all cases, except when you use hashtag anchors to jump to a div further on the page. Jump down.
In that case the top of the page clipped and started with the div I wanted to see.
Since you say the problem is pretty hard to track, this might be something to have a look at. The solution was to remove these 2 css lines and use another method of setting div heights.

Detect if address bar is shown in iPhone browser

I'm trying to detect, in a future-proof and device-independent way, when the address bar in the iPhone browser is showing. This is the toolbar that is shown at the top in order to display the URL. It can be hidden by calling:
window.scrollTo(0, 0)
What I'd like to do, is detect when it's being show (thus reducing the available viewing space) and set a timer to hide it again a second or so later. Any more frequent than that and it'll be quite annoying since users won't be able to get to the address bar.
I've tried checking window.pageYOffset, unfortunately, this returns zero if any part of the url bar is visible.
I don't want to hard code any dimensions on the iPhone and check those against the current viewport size. It's too fragile.
Anyone know a solution here?

The window.innerHeight property is what you're looking for. This is the height of the actual content on the screen. It's significantly less when the toolbar at the top is visible, because there's less room for the content. There is a slight problem that I can't seem to figure out on my iPhone 4 - window.innerHeight sometimes returns 3 pixels less at certain scroll positions of the screen.
I've set up an example for you that does more or less what you asked, it should at least get you started:
http://jsfiddle.net/rUSEb/show/light (test it out on your iphone).