I made a form script so that I can always use that if I need a form, but I noticed that when I set for a field the property on overflow hidden it still is visible in Firefox (tested in 3.6).
I saw that still more than 5% of the users look in FF 3.6 so I need to fix it.
I googled it for it but all the fixes they said didn't help me with my bug...
Link to jsFiddle I made a part on the form in JS fiddle, if you can test in chrome, IE 6+ and then FF 3.6 you see the differences (when you click on the checkbox the hidden content should show).
Please can someone help,
Sander
It looks like it is a Mozilla bug that has been going on for over 7 years (reported 2004-09-22):
https://bugzilla.mozilla.org/show_bug.cgi?id=261037
The problem
overflow is always treated as overflow: visible on a fieldset when it is assigned a fixed height or width (no matter what you set it as).
The Workaround
You could either use display: none to hide the fieldset content or if you want to carry on using the overflow:hidden approach then you could either change the element from fieldset to div or nest fieldset within another div with the property overflow: hidden.
Nested fieldset example: http://jsfiddle.net/8nbuj/8/
Related
I have an HTML grid where we use arrow keys to navigate the cells (like a spreadsheet made of divs). Each cell has an INPUT textbox. We use javascript to catch keyboard arrow keys to move around the grid. This has worked fine in all browsers for over a year. Now, with Chrome 39, the grid will no longer scroll properly so that the input with focus is visible on screen.
Here is a fiddle to demonstrate the problem: scrolling list.
// This causes scrolling into view on focus to stop working
$('#grid').on('focus','input',function(e){
this.select();
});
Use the up and down arrows to scroll through cells in the list. When it hits top or bottom, it should scroll into view if the new cell is not already in view.
This fiddle example still works fine in IE10+ and Firefox, but in Chrome 39 (latest version), it will not scroll when you arrow into a new cell off the bottom or top. Also, it looks like the textboxes redraw off by a few pixels sometimes.
When a new cell (input) gets focus, we call this.select() to select any existing text. If we remove the call to select(), then Chrome 39 works fine again. But, users would like to see text selected.
The question is: Is there something I am doing that would cause this, or is it a bug in Chrome 39?
If it is a bug, does anyone know a workaround to select input text without breaking the native scrolling into view behavior? Any ideas would be appreciated.
Update:
It appears that even removing ALL JS code, leaving just a bunch of inputs in a scrolling div also fails (only on Chrome). You can only navigate with tab/shift-tab without JS, but scroll problem still occurs. Am I going crazy, or do other people see the same screwy scrolling when running this fiddle?
See Updated Fiddle for example.
The problem seems to occur, in my experience, from a parent container with position absolute/fixed with z-index value. This affects Chrome 39+
Try setting that parent container to have the following CSS declaration:
-webkit-backface-visibility: hidden;
Well, it looks like it is just a bug in Chrome 39. Hopefully, they will get it fixed before too long.
Luckily, Chrome is also one of the few browsers that supports the scrollIntoViewIfNeeded() method, so as a workaround I was able to do something like this in the focus event handler:
this.select();
if (typeof this.scrollIntoViewIfNeeded === "function")
this.scrollIntoViewIfNeeded(true);
So, that solves the immediate problem.
Advise: it happens with fieldset, not with div. See the links with tests below.
In Firefox, this works, the content is cut off at 50px:
#someDiv {
display:block;
height:50px;
overflow:hidden;
}
but this doesn't works, all content is shown:
.openAndClose {
display:block;
height:50px;
overflow:hidden;
}
In Safari and Chrome, both CSS declarations works. Using the pseudo class is useful for divs that will open and (almost) close later by JavaScript. Otherwise I'll have to set every ID and if I decided to change 50px to 60px, all will have to be corrected.
Is there a way to make FireFox accept the pseudo-class CSS overflow declaration?
As your wish, two live tests:
With ID
With class
By the way, there was a stupid error, but now nor Id or class works...
It looks like you're running into https://bugzilla.mozilla.org/show_bug.cgi?id=261037, which is fixed in the upcoming Firefox 28. That's shipping about 5 days from now, so unless you really need this working in old Firefox versions I wouldn't bother with workarounds; just assume it will work.
If you do need to work around, you can try using a nested div inside the fieldset, with height set to 100% and the overflow style on the div.
FireFox has a different understanding of fieldset kind of element. However, as described here:
Content categories by MDN
it should be render as a div. Instead, is render as a transparent rectangle, maybe because is considered in the form context, but is unclear in the documentation.
Looking at this example os usage from Mozilla:
Example of fieldset usage by Mozilla
I did a cross browser version:
This will work in FireFox
The content is enlarging the frameset...
I don't know if FireFox is right, but the usage of fieldset should be more clear since there is a difference from other common content categories as div. I could not find a proper Mozilla forum to discuss this, I do think they should know about. If you know how can I better contact the developer team, please let me know.
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.
I'm trying to test for something's visibility with
$(this).css('display')=="none";
The problem is, it works in chrome, FF...but not in IE. I've tried IE 8 and 9 so far.
Does anyone know a work around? This is very frustrating as a bunch of people still use IE and I don't want to lose that bunch of people.
Use $(this).is(":visible") for a cross-browser solution.
From the docs:
Elements are considered visible if they consume space in the document.
Visible elements have a width or height that is greater than zero.
Elements with visibility: hidden or opacity: 0 are considered visible,
since they still consume space in the layout.
Read more: http://api.jquery.com/visible-selector/
and How to tell if an element is visible