-
Notifications
You must be signed in to change notification settings - Fork 915
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
keep height of persistent language tabs constant #1227
base: main
Are you sure you want to change the base?
Conversation
08fc355
to
35f4717
Compare
Geri, I know you were looking at some tabs stuff, can you take a look? |
Thank you @titusfortner, I'm looking into this later today. |
Thanks! This is merged in Selenium docs now. You can see this example: https://www.selenium.dev/documentation/webdriver/actions_api/mouse/?language=javascript#drag-and-drop-by-offset Clicking the different tabs keeps the same position, even though the previous tabs are very different heights. |
@deining Since you are the main contributor to this feature. Can you please take a look when you have a change? |
Well, something is wrong with this code after all. Clicking the tabs and measuring the heights isn't always giving accurate heights and I'm not sure why. If I throw a debug point and execute the code in the console it gives a different result from when it is executed in the js file. I have no idea if it's in a different context or what is going on. :( |
@AryanP45 you can see from this example: https://deploy-preview-1157--jovial-austin-42fe02.netlify.app/documentation/webdriver/browser/windows/?language=python#create-new-window-or-new-tab-and-switch There's something wrong in the calculations, and I just couldn't figure out the issue. For some reason clicking the tab in the JS and calculating the height was giving me different value than when I ran it in the console. I don't know enough JS to know how to fix it. Full conversation is here: SeleniumHQ/seleniumhq.github.io#1167 Would be really great if someone could at least figure out *why the JS isn't determining the correct tab-content heights when executing. I put in a debug point to ensure it isn't a race condition. Just no idea why it's happening. Can't hope to do a workaround without that. |
35f4717
to
2d51834
Compare
|
I can't reproduce the problem reported in SeleniumHQ/seleniumhq.github.io#1167 under macOS Chrome. @geriom, can you reproduce it? (Works fine under macOS Firefox too.) |
@chalin, same, I can't reproduce it either under Linux Chrome and Firefox. Edit: Nevermind, I was able to reproduce it once, after clicking the right hand side link to the header. I can't reproduce it again. The page is working fine except for that one time. |
Huh, when it happens for me it's been consistent, it's just not obvious to me why it happens in one place and not another. Seems to be the tabs with the most height? We could set it not to overwrite height value if the max height is over a certain amount, but those are the tabs that end up causing the most problems. :) |
2d51834
to
48f9160
Compare
48f9160
to
ec20dcf
Compare
Erf, but for some reason the tab height does not work when I combine it with #1202 |
I was just combining them incorrectly. This example includes code from both of my Docsy PRs: |
Updates
Re-implemented with a simpler approach.
persist=disabled
turns it off?A good example to see this working: https://deploy-preview-1530--selenium-dev.netlify.app/documentation/webdriver/interactions/windows/#print-page
Note that this page was the one that was giving problems with the original implementation here; still have no idea what wasn't working with that one.
Again, not a JS dev, but this seems to work as desired.I haven't merged it into my project yet (SeleniumHQ/seleniumhq.github.io#1157), but you can see an example by going here and clicking the "Kotlin" tab:https://deploy-preview-1157--jovial-austin-42fe02.netlify.app/documentation/webdriver/actions_api/mouse/#drag-and-drop-by-offsetNot sure if you prefer an additional toggle added for this behavior & I know the shortcode docs section would need to be updated, either way.