Layout corruption with ExtJs 4.1 and Chrome 25 - google-chrome

I have posted this on the sencha forums as a bug, but I figured getting it out on stack overflow could be advantageous:
http://www.sencha.com/forum/showthread.php?257622-Serious-layout-Issue-with-ExtJs-4.1-and-Chrome-25&p=943170#post943170
and a screenshot of it in action can be seen here:
http://www.sencha.com/forum/showthread.php?257508-Strange-behaviors-in-Chrome-25-with-Ext-4.1
Basically, with ExtJs 4.1, after upgrading to Chrome 25, our users are sporadically seeing layout failure in our application.
It usually is noticed by the window 'close' button appearing skewed on the left of a window instead of the right, and all the form fields displayed vertically. Once it happens, every subsequent component that is rendered is all messed up.
Reverting to chrome 24, or using Firefox makes the problem dissipate.
The issue shows up in IE when running Chrome Frame 25.
We have disabled our custom CSS, and still seen the issue.
Any ideas?

Amphro's answer does address the issue, but doesn't completely eradicate it.
The only real solution I have found is to upgrade to ExtJs 4.2.
I can still replicate the issue with ExtJs 4.1.2 in Chrome 26 as well.

We were experiencing a similar issue with our Ext application. We finally narrowed it down to floating numbers in the height and width of panels. For example, if you have any code that looks like panel.setWidth(v1 / v2), change it to panel.setWidth(Math.round(v1 / v2)). Hope that helps.

Related

Chrome Bug!? - infinite scrolling above page body (several Pages)

I recognized this Bug on several Pages occurring in Chromium related browsers. I opened up a Chromium Issue, where the project members could not reproduce the problem - I am trying to figure out why this is happening (since the Problem occurs on Pages as like google.com, amazon.com, and so on, on several Mac-OS devices, which have nothing else in common) - we tried it on a clean Chrome installation, where The Problem is also occurring. To me it seems to be a bug - now I'd like to know if other people are also not able to reproduce. If you can reproduce (to reproduce read the following lines below) and/or find something new/interesting about the problem consider supporting the Ticket/Chromium Issue.
Chrome Version
91.0.4472.101 (Offizieller Build) (x86_64)
URLs tested
https://www.google.de/
https://www.microsoft.com/de-de
https://www.amazon.de/
Other browsers tested
Safari: hasn't the problem
Firefox: hasn't the problem
Edge: has the same issue (also Chromium based)
Chrome Canary: has the same issue (also Chromium based)
How to reproduce the problem?
Refresh Page (Command+Shift+R) and Scroll upwards while page is loading or in parallel (you have to be quick to reproduce).
What is the expected result?
Expectedly the Page should not over-scroll and stop at the pages top/end instead the page can be scrolled infinite above the pages top, same issue appears by scrolling down, where scrolling should stop at the bottom of the page.
What happens instead?
Browser keeps scrolling above the pages top/bottom infinitively. Once triggered the infinite scrolling wont disappear, even after refreshing the page - the only way to change the behavior is to copy the url and paste it within a new tab.
Small update: it seems like the problem appears when using a logitech mx master mouse (if you run into the problem when not using this specific model, let the chrome people know) - it looks like it can be solved by following steps:
Open a terminal window.
Type in the following command then hit enter:
defaults write -g NSScrollViewRubberbanding -bool false
Source: https://www.computerworld.com/article/2726533/turn-off-elastic-scrolling-in-os-x.html
Hopefully they'll fix the problem in chrome itself, until then this should solve the problem.
Update: See Irgend Son Hansel answer
I don't think there's an official fix currently, but what I do when this bug comes up is to simply click the scroll bar. It usually fixes it for a while before it comes back up again.
I am not entirely sure what the OP is asking but I assume they are looking for a fix or a workaround for this?
I occasionally experience the same on my MacOS machine. For me, refreshing page does not work. What I do is the following:
copy url of the current page
open new tab and navigate to the same url
close old tab

iOS keyboard pushes content up

My code is open source and that particular branch is currently deployed so you can see what is happening if you have an iPhone.
I've captured what is happening to show the problem.
This is only a problem on iOS, I am testing this with my iPhone SE, but I imagine newer iPhones will have the same issue.
On Android, this problem does not exist. It looks fine on Android!
The search input should be at the top, ready to receive input from the user.
How can I make it behave the same on iOS? I have already tried:
Giving position: fixed to the body.
I already tried window.scrollTo(0, 0); here.
UPDATE
I've created a little HTML/CSS file as a playgournd specifically for finding a fix. It is deployed here.

Screen resolution trouble in different browsers with Aurelia Framework

I'm learning more about Aurelia and while trying to migrate some layouts from HTML5 to Aurelia, I found that everything looks bigger when inside an aurelia template. Even the simplest layout possible, without any css styling or lib, looks bigger here compared with the raw HTML.
My monitor resolution is 1920 x 1080 and looking in Developer Tools, the HTML tag width is smaller (1920px width in HTML file vs 1280px in Aurelia rendered page).
I also tried my app in Google Chrome, Mozilla Firefox and Microsoft Edge and the only showing it how it should on both examples is Edge.
Here is a screenshot of same application on both browsers:
Playing with zoom on developer mode I discovered that if you put zoom: 1.5 on the left one, it gets the same size of the right one and zoom: 0.66 on right get the same of the left.
Does anyone know how to fix this? I'm getting crazy about it!!
Edit:
Here is another example with Chrome and Firefox. Attention to the sizes:
No css at all on these examples!
Since I didn't find why it was happening, I reinstalled my browsers and the problem is gone! I failed figuring out the reason it was happening but for now, that's enough for me.

ZURB Foundation rendering problems on Chrome for Windows

I am having a strange problem with an app developed using Foundation Framework.
It seems that there are huge rendering problems, especially during/after scrolling. It may happen that images do not scroll together with the rest of the elements, but they remain static (as if they had fixed position with z-index -1), therefore messing with the other elements.
The issue happens only with Chrome for Windows (tested versions from 35 to 41). While on the latest Chrome (42), released yesterday, the issue is not happening.
It doesn't seem to be a known issue, but I have checked my code and everything looks perfectly fine. After all it works in every other browser perfectly, EVEN ON CHROME FOR MAC!
This is a screenshot of how the application should look.
Here are some of the rendering problem happening on Chrome for Windows after/during scrolling the page: Here, here
Any help on where this might come from, is appreciated. Thanks
Removing the height 100% from 'html' and 'body' solved the problem.

Why is this layout broken in Chrome?

This site: http://www.whsc.ie/ uses a jquery lightbox style plugin which seems to be breaking the layout in Google's Chrome Browser. When viewed in Chrome, the header of the site is about 30 pixels taller than it should be.
When inspecting the source elements it appears to be caused by some hidden elements that are used by the colorbox jQuery plugin.
I've tried everything I can think of to figure this out and fix the problem but to no avail.
Many thanks in advance.
My Bad!
It seems it's actually a Wordpress bug that only appears when a user is logged in. I kept seeing it on the browsers on my own machine because they were all logged in, but when I went to a different machine the bug wasn't visble.
Thanks for the replies though, much appreciated.