I am trying to find out how some inline css is being added to my html when the page is scrolled down.
I am using chrome dev tools. I think it is supposed to be in console, but I don't see anything show up in there when I scroll the page and know that the javascript is being fired. I assume it is javascript.
When I scroll down the page the header size shrinks to a set amount of pixels. I want to change that number but I can't find the source of what is causing the change.
Inspect element that gets inline styles set.
Right click on it in the Elements tab.
Choose Break on.. -> Attributes Modification.
Scroll the page.
JavaScript execution will stop on line that modifies any of the attributes (including 'style').
If you'll end up in the middle of jQuery/Angular/etc. - look at the Call Stack in the Sources Panel. It should reveal the higher-level code that modifies the styles.
Related
My dashboard app is a single page - never longer than 100vh.
In a certain place, when I click a button, some unknown container temporarily overflows and a scrollbar appears on the right side, and then one second later it disappears. During that one second, the page background jumps very noticeably.
I wish to prevent this scrollbar from displaying via CSS - but I am having difficulty identifying the container that is overflowing.
Does anyone know of a method or a trick to identify which div is displaying the scrollbar right now, or which div has overflowed the screen? I've been at this for a while and thinking, there's got to be a DevTools trick for quickly finding this...
If this happens during an action I would ask myself which are the DOM elements that are loaded at this moment and I would probably try to add something like overflow: hidden; on the elements loaded at this moment to see which one Do it.
If there is javascript, breakpoints can be useful.
It is also possible to put some on the DOM (element inspector, right click on a div or other elements then "break on" and "subtree modification" for example)
I find the breakpoint very practical to go back to a problem.
Here's how I used Hadock's answer to solve my problem. Using the Break On Subtree Modifications (BOSM for short), I was able to do the following:
I set BOSM on a div that I thought was just above where things were being added, and re-ran the app.
The app paused with the scrollbar displayed - exactly what I wanted.
In DevTools console, I entered the following:
[...document.querySelectorAll('*')].filter(x => x.scrollHeight > 1000)
this returned all Divs with big scrollbars (height > 1000px). In my case, they were:
html
body
#react-entry-point
I was able to add the css:
#react-entry-point{overflow: hidden;}
and my problem is resolved.
This might not be a good solution for everyone, but for me, with my 100vh (max) one-page application, it did the trick.
Here are some other useful (related) console commands:
Display all containers that might have a scrollbar displayed (courtesy of user A1rPun):
[...document.querySelectorAll('*')].filter(x => x.clientHeight < x.scrollHeight)
Display all containers with a scrollbar > 150px:
[...document.querySelectorAll('*')].filter(x => x.scrollHeight > 150)
I maintain a library, react-to-print. The library provides a React component that at its core has two inputs: a trigger (usually a button), and content. When the trigger is clicked, the library will copy the entire DOM representation of the content and put it into an iframe. It will also copy all style links on the page to ensure the content is styled correctly within the iframe.
A while ago, someone raised an issue (the end of the thread explains the core problem) concerning the library's seaming inability to print content that was horizontally scrolled, in this case, within a table. It turns out that what is actually happening is that a component within the content is virtualizing its render, meaning only content this is visible on the screen is actually being rendered. So the issue is that react-to-print is not maintaining the scroll positions of child elements when it copies them into the iframe.
I know how to scroll the entire page itself inside of an iframe, but do not know how to maintain the scroll of individually scrolled DOM elements that are children of the window. Is there a way to do that?
While an ideal solution would of course be just turn on a setting or something and done, I'm guessing that, if a solution is possible, it will look something like:
Iterate over every element on the page
If the element has a scroll, save its scroll position in a map
Copy over the elements into the iframe (as is currently done)
Iterate over every element in the iframe and apply a scroll if one is found for it in the map
As you can see from the screenshot that Layout is triggered on root element (#document) in every frame which causes next operations like paint.
This Layout is caused by Recalc Style which I am not able to understand why it's happening. There's no script running. Just Recalc Style > Layout > ...
I need to know why such Recalc Style could occur without script?
Additional Information:
This page is using Semantic UI framework
It contains a custom grid
This Recalc Style > Layout operation is performed in ever frame even when the page is idle.
First, is this even a problem? Unless you're experiencing performance issues, don't waste time trying to prematurely optimize.
Next, enable the Chrome rendering settings to show a what areas of the screen are GPU layers and what parts are being repainted.
Style recalculation and painting can happen for many reasons that have nothing to do with javascript. Browser resizing, tables performing rel-layout as new items are loaded during the page load, etc. Since you didn't provide any information about the page that's being loaded, it's hard to say.
My guess would be that you've got some kind of CSS animation that's being applied to a property other than translation, rotation, scale or opacity. All of those properties are GPU accelerated and won't trigger repaints, however, fading background colours, changing border thicknesses, even adjusting top, left, right and bottom properties all cause repainting.
You've mentioned that you're using Semantic UI. Either Semantic or one of its themes are causing this redraw to happen. Your screenshot doesn't actually prove that scripts aren't being called.
I'm taking a look to this website http://planetshine.net/demo/regolith-wp/ trying to understand how the horizontal layout is obtained.
I'm just trying to disable the javascript libraries one by one (I want to identify those essential fot the layout and those less important). And beginning to disable only the "buttons.js" library the layout already changes (for example, the vertical scroll bar appears). I would understand why this script "buttons.js" is so influential for the layout.
Some CSS styles may be added by javascript after a page is loaded. This often occurs in plugins: sliders, custom scrollbars etc. You need to inspect places, where this happens and find out, which classes or html elements disappear. Then you can recreate them manually and the whole page will work as expected.
I was looking at an issue in JIRA (e.g. here, an issue in JIRA 4) and I noticed JIRA 4 has some interesting scrolling behaviour, where when scrolling down with the main browser scrollbar,the jira header scrolls up out of way, then the issue title stays fixed at top, then the rest of the issue continues to scroll. So the issue title is always visible.
There isn't an extra vertical scrollbar. Its all scrolled via the main browser scrollbar. So its either css or javascript magic! Any idea how they do that?
Cheers,
Phil.
It changes dynamically the div #stalker which has position:absolute;top:76px;. When the user scroll, change the position to position:fixed;top:0 and keep it in a fixed place, giving you the ability to scroll the rest content.
Edit
I created an example of this behavoir, because I was curious and here the demo if you want to check it http://jsbin.com/igiji5/3
Atlassian published the source of the Javascript at http://docs.atlassian.com/aui/3.0/jquery.stalker.js.html
That is created using JavaScript.
I can see by using FireBug to inspect the div#stalker that it changes class and style attributes when you are scrolling.