I'm setting the selection background color via CSS:
::selection {
background:#cc0000;
color:#fff;
}
::-moz-selection {
background:#cc0000;
color:#fff;
}
On most browsers when the focus is somewhere else (like an IFrame), the selection color will stay the same, e.g.:
but on Firefox it won't:
You can see this in action on jsFiddle here.
How can I get Firefox to set the selection color in this case? Is this a bug?
How can I get Firefox to set the selection color in this case?
Unfortunately, there doesn't appear to be a way to do so.
Is this a bug?
Nobody (including Mozilla themselves?) can say for sure; this was never specified while ::selection was still in the CSS3 spec. I can't find any information on MDN or bug reports on bugzilla.mozilla.org on this either. but I did find this bug report, which has apparently been left unresolved since being reported in 2010.
This may be clarified in the future, e.g. if ::selection returns in UI 4.
Related
I've been developing a web-ui for a while and it has become now quite complex. At a certain place I use a <div contenteditable="true"> for editing text, and there is a bug in FireFox, which I cannot trace down:
When there is some text in the div, and I click with my mouse to change cursor position, it doesn't work. The cursor is always in the end of the text. It works fine in other browsers, and you can change cursor in FF using arrow keys.
I tested a simple html page with a single element <div contenteditable="true"> in it in FireFox, and it works fine, but doesn't work on my system. Obviously, there is something that blocks it.
What can be a possible issue?
Thanks!
I had the same issue and finally found that the issue in my case was CSS wise. I had:
-moz-user-select: none;
on a parent element of my contenteditable which caused the problems.
It worked well after I applying:
-moz-user-select: element;
NOTE: depending on which select behavior you want to have, choose the user-select value (https://developer.mozilla.org/en-US/docs/Web/CSS/user-select)
for me it didn't work because on the parent div is a drag & drop implemented. and it effects all input-fields, textareas and div's with contenteditable.
I haven't found a solution for it yet but there is already a Bug Ticket for Firefox with the right hint that draggable makes the problem.
Here is a link to the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=419808#c4
Here is a way to fix this problem:
Prevent drag event to interfere with input elements in Firefox using HTML5 drag/drop
I'm getting this really annoying problem with my dropdown menu in Safari & Chrome for both Mac and Windows.
It seems fine in other browsers, even IE7+ (shocking I know).
The dropdown is supposed to be absolutely positioned to the parent <li>, I've set left: 0; however the dropdown is showing underneath the following <li> instead.
I've had this problem in IE in the past, but I'd expect better from WebKit!
Also, here is the problem looks in Safari (different, but I imagine the cause is the same):
Here is a link to the page (hover over the 'Blogs' link):
- http://www.mattpealing-server.co.uk/~devfooty/
Does anyone know how I can go about fixing it? I've tried all kinds of combinations, even found out that if I position bottom: 0 then the dropdown appears under the correct <li>, however obviously it then doesn't look right! Strange though.
I am not sure if this would work but you could try setting the parent element's position to relative.
I've come across a problem in Firefox browser. It's likely a bug, but maybe someone knows a workaround. The problem is demonstrated in the following JSFiddle: http://jsfiddle.net/F5tdB/ This has been tested on Firefox 12.0, 15.0.1, 16.0.1.
To explain it in words... You have to follow this sequence of events:
Get an element with overflow:auto and some overflowing contents, then scroll it a bit;
Hide the element (display: none);
Remove contents
Show the element (it's empty now)
Re-add the same contents (it's scrolled now, just as it was before)
Reset scrollTop/scrollLeft to 0 via Javascript.
As a result, the contents do get scrolled to the proper position, but the scrollbar stays as it was, which is clearly wrong.
Is there any workaround to this short of removing/re-adding the element instead of just hiding it?
In testing I discovered that if you set scrollTop to any value other than 0 (or its current value) then it updates the scrollbar correctly. You can then immediately set scrollTop to 0.
Particularly as you have a test case you should of course file a bug in Bugzilla.
Solution is add the animate method, so use:
function resetScroll(){
$(document).scrollTop(1); // removes the impression of animation
$('html,body').animate({scrollTop:0},'fast','linear');
}
My jScrollPane (division) works well in IE and Chrome. It may be of some significance that I am also running JQuery MouseScroll and hoverintent. Again, these functions work fine in IE and Chrome.
The division is displayed properly in Firefox, as is the vertical scrollbar. There's about 50 lines to scroll down through.
In Firefox, the dragger fills the entire length of the vertical bar and doesn't move. The dragger and the arrows do respond to mouseover, but the functions don't work.
Perhaps the scrolling action is functional, just that there is no space to scroll, because the dragger fills the entire region. I am unsure whether my jScrollPane works or doesn't in Opera or Safari.
I checked Google and found little directly associated advice, just to:
"Ensure that the division has a height specified (it does) and to try refreshing (no luck) in case the content (only text) needs to pre-load."
I wonder whether anyone can suggest any checks for me to make from their previous experience before I post any code to wade through.
This is only the second question tagged with jScrollPane & Firefox, so perhaps no-one will be familiar with this 'bug'. In which case I will create and post some reduced code which generates this bug in Firefox but not IE or Chrome.
Update: I created a 'test' scrollbar webpage to see if the bug would be replicated, and that works fine - so no need to post that for error-checking.
The problem must lie somewhere within my code on the site I'm working on.
So far I have identified that all the JavaScripts work and my custom jScrollPane CSS is fine. So it's just a process of elimination through each of the stylesheets now. I have a feeling the source of the bug may be in my custom reset CSS.
I'm confident I'll fix the bug, and will let you folks know either way.
The bug was in the CSS reset as suspected. Specifically, with the rule for column-count.
I had defined them (moz-/wekbit-/column-count) as '1' instead of the defining as 'auto' / not defining it at all.
This was from when I was experimenting with (CSS3) multi-column text. Presumably jScrollPane requires multiple columns. Not enough support yet for multi-column text to be worth implementing yet IMO.
Is there a 'valid' solution for the dialog to scroll with the scrollbar instead of still being fixed from the center of the inner window bound ?
There is some situation where the user may have a too small resolution to contain the dialog, and in that case part of the dialog maybe hidden.
You may have a Ok or confirm button in the hidden part, and then the popup may not be closed, nor validated ! Blocking situation.
I tried to change a css into the code from fixed to absolute, and then the dialog scroll with the page: great! But... Meanwhile doing this, opening another popup, do not position it again centered into the layout. Maybe a solution is to recenter the dialog on each onOpen event.
Any help welcome.
The dialog was written to be fixed and as such is not easily changeable.
You could change the position to absolute, but all of the IE hacks will force it to behave as fixed.
In SimpleModal 1.4.2 you can simply set fixed to false:
$('#myModal').modal({ fixed: false });
This worked for us on Chrome and IE all the way back to IE8. (We don't support IE7.)