CSS : Firefox right click selects all on my site...why? - css

I have built a context menu but have found annoyingly that when I right click on my site in firefox all text and images just seem to randomly get selected. It is not a JS issue as I have removed all JS from the site. Thinking it must be a css issue. I have never encountered anything like this before...
I don't have an example page to show I'm afraid. Has anyone experienced this before in Firefox. I am using the latest FF4.
Cheers Guys!
*UPDATE:*
Here is a pasting of the pure html from the page that is having issues,
http://jsbin.com/aneja4/3/edit

did you try to disable all your addons you have installed? maybe one of them is causing the problem.
I have FF 4 but neven encountered this problem before.
And I could be wrong but I don't know of any css code that would be able to select text. it's pure for the design and structure of the site. it will be mostlikely a js problem or something else

I have seen this too... I think it has something to do with the way the site is structured... If you have nexted divs, or a div that does not quite cover the entire page, a right click on the parent div seems to select everything in the nested div. It's quite annoying... especially when trying to build a custom context menu, or use the default menu to refresh the page...
Any fixes/changes that we should know about for FF that is causing this? I'm using FF4 and XP (yeah, yeah... corp. system)
JF

It's likely a problem with your HTML layout that firefox is struggling to work with. But without seeing any code, it's not possible to speculate any further down that path. #JDF's suggestions may help you, though.
If you can't work it out, and can't live with it, you could just disable the ability to select text.
In Firefox (and other standards-compliant browsers), you'd use the CSS user-select: none;.
See this question for more info on how to achieve this: How to disable text selection highlighting using CSS?

This is most likely caused by having a contentEditable element on your page. Any element (other than body it seems) that contains editable content will be highlighted/selected when you right click on it in Firefox (4.0 and 5.0 is all I can confirm). If everything on your page is wrapped in a div it'll appear that the whole page is selected. If you (can) right-click somewhere on the body the regular context menu should work.
Although I can't see any instances of contentEditable in your code on jsbin, it could be added by a script that I can't see (possibly even modernizr?).
I think this is related (although it doesn't match exactly)
http://support.mozilla.com/en-US/questions/766166
http://aloha-editor.org/ exhibits the same behaviour when right-clicking anywhere inside the #wrapper div.

Related

Monaco Editor Intellisense Not Full Height

I am using Monaco Editor 0.22.3 in combination with StencilJS and TailwindCSS. Everything works great, except for an annoying visual glitch in the intellisense dropdown as depicted here:
As you can see, the last suggested item is partially obscured.
I suspect it might have something to do with some style coming from TailwindCSS, but I'm pretty much at my wits end here. I tried to use the F12 element inspector to see if I can find some hints, but that is proving to be close to impossible since the intellisense dropdown disappears as soon as it loses focus.
Any hints would be much appreciated!
UPDATE 1
Here's a screenshot with a bigger editor to demonstrate that the dropdown itself does not appear to be clipped:
UPDATE 2
Here's an animated gif showing the issue when trying to debug the HTML elements using the browser developer tools:
As you can see, the dropdown disappears as soon as I click anywhere else.
The issue comes from a fairly common css class being used: .tree. Libraries such as tailwindcss add padding-bottom to it for example. To undo some of its additions for the monaco editor we added the following to our css file:
.monaco-editor .suggest-widget div.tree {
white-space: unset;
padding-bottom: 0;
}
And to get get to that solution for other libraries and styling artefacts:
It should have been quite easy but the suggestion dialog has a tendency to hide when we try to observe it. so a UI guy and I spent a while going through the playbook to try to debug it. The only successful way to inspect it was to abuse the JS debugger by running (which was a hint from a stack overflow post that I'm struggling to find to give credit), and just cause the JS engine to pause:
Run:
setTimeout(5000);
This gives us 5 seconds to get the suggestion window to show (or set to a relative amount of time to the problem). After which, you could mostly inspect it as normal with a quick shortcut:
ctrl+shift+c that brings up the debuggers element selector.
Here we are, the suggestion was from the following post:
How can I inspect disappearing element in a browser?
break on subtree probably would have worked, but we became a bit impatient stepping through the changes. ctrl+ / didn't seem to help in this case, which left the odd setTimout to save the day.
The drop down is clipped at the editor's boundaries. I actually wonder how you can see the last empty part outside of the editor.
For inspection: use your browser's dev tools to see how the containers overlap. This will avoid that the editor hides the drop down.
Update
After your update I think now that somehow the styles are messed up. You will have to figure out a way to show the popup and still navigate the DOM tree in the developer tools. Try to locate the parent and see if that popup is only hidden (it still shows up then in the tree) or if it is dynamically created or is a portal, which lives in a completely different part of the tree.
If that cannot be done then try to disable all CSS you have and see if that solves the issue. If so enable the CSS piece by piece to find the culprit.

IE10, Same Domain IFRAME and Style shset

In my application, I am including one page within another via an iframe. I'm working on a quick prototype here, so I don't want to take additional time right now to implement something fancier].
Everything looks good except for IE10 on Windows 7. From what I can tell, the style sheet of the iframe is being added into the cascade of the style sheet for the page and causing strange display errors. I'm a little dumbfounded this is even possible.
If I comment out the iframe, everything renders correctly.
I can also see the styles changing as the iframe loads:
Pre-iframe: http://screencast.com/t/8qcl2U4Uuy
Post-iframe: http://screencast.com/t/fzR9esWsq
Anyone else experience strange behavior like this?
Thanks in advance.
Thank you for your reply. My coworker was actually able to help me trace this back to an issue with the IE10 developer toolbar.
I was able to create a file that replicates the issue: https://dl.dropboxusercontent.com/u/1686497/iframe.zip
If you open the index, you'll notice that there is no margin on the body. While you have that page open and you open the F12 Developer Toolbar in IE10 (10.0.9200.16540) on Windows 7 (at least), you will see the body becomes padded and the parent window font switches to Times. Hope this helps someone!

CSS messing gridview button?

For some weird reason all the buttons I place inside any gridview appear as really shrunk (like in pic below) even though the gridview is default and has no CSS attached to it.
Could it be some other CSS as I have way too many code to list it here (downloaded free template)?
What could the problem be? How can I fix it?
It is inheriting some style from parent or global input css file. To know where exactly the problem is use IE Developer tool...Select the button in the developer tool and see styles that are not crossed out on the right side of the developer tool

Site visualization problem with Chrome

I have a site based on Solar Sentinel Joomla template: www.sism.org
I'm having some visualization problem with chrome.
The right side-bar is shifted down after all the content, while it should be floating on the right!
Could someone explain me why?
PS: the template css is pretty messy, and there is some custom css and js made by me inline at the beginning of the page.
The HTML is throwing a lot of validation errors: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.sism.org%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
My guess is that Safari and Firefox are rendering around these errors in a way that is according to what you would expect. Try fixing the errors and seeing what happens. If nothing else, you'll have ruled out invalid HTML as the issue.
It looks like your div class="col3" is inside your div class="colright".
Try placing div class="col3" outside the other one.

drupal - problem with quicktabs

Hello
I have quite a strange problem using quicktabs. I used the framework theme to develop a custom look for my site. I used quicktabs in the center content area to create a tabbed look for placing links within the body. Everything is working fine. However, when I view the site in IE8 at a resolution if 1024*768, I have trouble with a few links. It seems that sometimes the first link under my buttons are difficult to click. The link is there - I can actually click it, but it is very difficult to locate - it only appears at the very beginning of the link text - it is not the first letter, it seems to be only the first pixel.
I looked at the source and everything seems to be correct - I can't figure out what could be wrong.
Has anyone seen any similar behavior that might be able to point me in the right direction for a fix for this?
Thanks for any thoughts.
Edit - I looked further into it and I think it has something to do with my CSS. I disabled css in ie8, and every link is clickable, even the ones that were difficult to locate earlier. I guess there must be an overlapping of containers or something, so I will have to start messing around with those files.
It sounds like a CSS thing, have you inspected the elements in question using the developer tools (press F12) to see whats going on?
I found the solution. In the style.css file for my theme, the .block had position: relative; applied to it. removing that bit of themeing appears to have fixed the link issue.
Thanks

Resources