I'm trying to make a rich text editor with the background set on iframes body.
The background is repeated in y axis and when the user types in the string without any spaces the horizontal scroll appears and the background is moved to the left. I fixed it with overflow-x:hidden in all browsers except IE 8 where the behaviour is the same as with overflow:auto but without horisontal scrollbar appearing after the text gets beyond the intended width.
I want IE 8 to clip the excess content which can not be wrapped the same as with other browsers.
Has anyone had a similar problem?
been a year. You might have already found your answer, but anyway,
Yes there is a problem with IE - iframe - and Scrolling
IE doesnt render/accept style="overflow: hidden".
To remove scrolling, set attrib of iframe: scrolling="no"
However, I don't know how to set/unset scrolling for only one of the axes..
All the best. Do let us know if you find anything further.
Cheers!
Kris
Related
I'm making a webapp and want to use all the screen and avoid scrolling if possible. There will be buttons that need to be clicked in many areas of the page.
The area at the bottom of mobile safari is not clickable when the tab bar is open and I rotate to portrait and back to landscape.
I have set the body height to the same as window.innerHeight instead of 100% so that I don't have to scroll to get to buttons at the bottom.
bodyEl.style.height = window.innerHeight + 'px';
It may be the case that this area is not usable for interactive content.
Here is a demo with code:
http://plnkr.co/edit/327sUQ?p=preview
You should be able to open a preview of it on iPhone 6 Plus by clicking on the fullscreen button 'Launch the preview in a separate window'.
Update:
It definitely looks like it was a bug in iOS8, it's working as expected in iOS8.4, 9.0 & 10.2 from my simulator.
I may have found an answer to your issue, but would love to hear if you can confirm. Setting the content of your page to have the following styles:
overflow-y: scroll (allows you to scroll below the viewport, but only if necessary per the length of the content; the default value is visible)
-webkit-overflow-scrolling: touch (to smooth any scroll behavior)
in addition to your height: 100% (which forces the content to fill the viewport)
appears to force the iOS menu (tabs and address bar on top as well as nav bar on the bottom) in Safari to always appear. That way, button clicks to the top and bottom of the page are no longer "dead zones" and will actually work instead of opening up the Safari menu.
I'm searching for a solution for a similar problem - this is not an answer, but an attempt of explanation.
First of all - currently, I cannot confirm this behavior - seems like it's fixed in iOS 8.4 (12H143). Didn't know exaclty in which version I saw it the last time.
Nethertheless, I try to explain what I've found out (until we decided to not bother anymore).
The not clickable area is not always a dead zone. If you scroll up before you click, chances are high you get it working. Thus I think the (empty) standard navigation bar is there (height and behavior of the elements are similar/the same), even if it's empty (all element moved to the address bar) in landscape mode.
Btw.:
There's another (similar) problem with the iPhone 6 plus (not fixed yet).
If you have a position: fixed element on the top of a webpage, in landscape mode and only if there are two or more tabs open (and the tab bar is visible), you can click through this element (even through buttons) - as if the whole thing isn't there.
I know this question is a bit old, but since the issue still exists I thought I should share my experience...
As of now there is NO fix for the issue, but there is a workaround. The solution jennz0r provided may work for some, but I didn't like the idea of the menu bar always showing. I saw a website that had the issue solved... well it seemed to work at least. I didn't find anything in their css or js.
So what was the fix? Since the "dead zone" is 44px in height they simply made their floating bar 88px height :D Users would instinctively tap on the top/center of the button and it will almost always work at first try!
Another workaround would be to simply make the button/bar float 44px from the bottom.
"If it's stupid, but it works... it ain't stupid..." ;)
Have come across this problem when testing some older stuff in IE 11. Example here:
http://codepen.io/Samih/pen/zaqjA
Basically, when you have a display: table-cell element which has contents positioned absolutely, it works fine until you modify the content of that absolute container. You can see this by clicking one of the table cells in the example.
In Chrome, Firefox and even IE 10 this does not cause a problem, but in IE 11 you can see that the table cell height disappears to 0 and does not come back until you do something like resize the window.
I have tried a hack solution that involved using javascript to alter the cell size and then change it back, but it proved unreliable in the place I applied it. I'd much prefer a CSS based solution if anyone can come up with one.
I found an answer myself. Applying display: inline-block to the position: relative element fixes the problem in IE 11. I've no idea why, mind - but it works!
I have a standard text area with a lot of content which shows overflow, when I lose focus on this text area by either clicking out or tabbing out of the text box the cursor within the text box jumps to the top.
Plus when I stop typing the same occurs
Is there any way to prevent this with jquery or another means? I am unsure if it is a bug in IE8 but this is a client request.
Thanks in advance
This is a recognised bug in IE8, but there is no patch/hotfix available that I'm aware of (plus, even if there was, there is no guarantee the computer viewing your page has the patch/hotfix in place).
This happens on textboxes which are using a percentage width, rather than fixed width, and there are several recorded "fixes", although not all worked for me...
Firstly there is the option of fixing the width of the textarea via CSS, but also using min-width and max-width to set the percentage (however, this isn't going to work in old browsers). This could not work for me because the sheer number of textareas I use that all need different widths.
textarea {
width: 700px;
min-width: 100%;
max-width: 100%;
}
Here is an article from somebody who originally found the bug, with an explanation of the above.
Secondly, you could try setting the number of columns to be much, much larger than the visual size of the textbox. Here is an answer giving details of how to do this, and why they think this is the problem. However, I couldn't actually get this to work, despite it being the accepted answer with several up-votes.
In the end I choose to force IE8 into using compatibility mode using the following meta tag at the very start of each page (I use ASP.NET master-pages, so this wasn't a big job).
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
This will also made the "compatibility" button disappear, so it's impossible for your users to accidentally put it back into IE8 mode.
We are baffled by a horizontal scroll that shows up when you scroll to the bottom of Firefox and on the iPad 2 (running Safari).
In Firefox on both Mac and PC, according to Firebug all elements are the correct size. yet there is this grey area if you scroll. The scroll bar does not reflect this extra space; you need to access it via a trackpad. On the iPad, the grey space shows up as part of the body. That is, the browser thinks the site is 200 or so pixels wider than it is. It works correctly on the desktop Safari.
I've gone through every child element and everything fits. Any help would be so appreciated.
!
Thank you!
Here you can see the grey space we don't want!
Not fully understanding your question either - the image confused more than it helped, but my first suggestion would be in your CSS, set overflow: hidden to your body or main container divs.
EDIT: Firefox 2 windows XP
Steps to reproduce problem:
Firefox 2 and visit: http://resopollution.com/rentfox/html/property_setup.html
Begin Typing and pressing [enter key] to create new lines
After about 10 [enter key] presses you'll notice the screen shaking
How this happened
This began happening after I installed a plugin for jQuery. It's located here:
http://resopollution.com/rentfox/html//js/textarea.js
It makes it so the textarea is expandable as I type, depending on how many lines there are in the text area, up to a max-height value which can be specified in CSS.
I tried disabling the 'setHeight' function within this plugin (the only thing that changes height dynamically) but I still saw the screen shaking.
When I think the problem might be
Firefox thinks that the screen just got larger, and compensates by putting in a scrollbar on the right side of the body document.
However, it realizes that in fact the page didn't get larger, and removes the scrollbar, causing the shaking.
I have no idea where in the code that makes Firefox think this way...
Appreciate any help.
You can either force a scrollbar: http://css-tricks.com/eliminate-jumps-in-horizontal-centering-by-forcing-a-scroll-bar/
or hide the overflow of the div and try to get rid of the scrollbar, try overflow: hidden instead of auto in the div propertySetup
Can't reproduce, works fine here in Mac OSX + Firefox 3.5.
I can reproduce it (Debian Lenny, IceWeasel 3.0.6), but only with a very, very specific window size for FireFox (just slightly taller than 1024px, depending on your system font size, window manager and number of toolbars shown).
Just make your page slightly shorter or taller and the problem goes away. The problem only occurs when the addition of a new line after the 10th or so causes firefox to grown the page just enough to cause the scrollbar to appear. Just as you guessed.
That's a tiny 10px margin that is dependent on a lot of browser and system specific settings. In your page that margin is somewhere around the 1024px limit, depending on system font, toolbars, window decorations and the phase of the moon. Move that margin out of the 1024px region. Either make the page 40-50px shorter so that the scrollbar does not appear (even with large system fonts and an extra toolbar) or make it taller so the scrollbar is always there. Zoltan Lengyel's answer in this thread to always force the scrollbar can also be used.
I can reproduce it in Firefox 3.0.11 in Win XP.
Adding overflow:hidden to the body tag seemed to fix the problem, but doing that may wind up causing you more grief then disabling the plugin altogether. Giving the body tag overflow-x:scroll will stick a scrollbar there permanently but seems to solve it, too.
I reproduced it on Windows, FF3.
Interestingly it seems to happen within the jQuery .height() function!
Unfortunately you're using the minified version, so that's as far as I can get.