I am developing Javascript app that will wrap every line of text entered inside iframe (designmode) with P (or div) like it happens by default in IE.
For now I am not pasting my code because I just started, the first problem is when i type some text in firefox and even before I click enter or calling any function firebug inserts
<br _moz_dirty="">
under the entered text.
Why? How can I prevent it?
If you still need my code please tell.
As the _moz_-prefix suggests, this is a Mozilla-internal property. It isn't inserted by Firebug, but rather by the core editor functionality in Gecko. You can't prevent it; ignore it or work around it.
#myEditableDiv br {display:none;}
It's something Mozilla uses to prevent empty containers collapsing and occasionally inserts at seemingly random times too.
The question is, if they knew it was a dirty hack then why did they do it?
The _moz_dirty attribute is used to indicate that the node needs to be pretty-printed when the document is saved, although it shouldn't appear in web pages, only in SeaMonkey Composer and SeaMonkey and Thunderbird's HTML Message Compose.
The Gecko editor used to put it there because it needed it to give it somewhere to put the cursor. I believe this is fixed in Firefox 4.
Related
I am trying to write a bit of code in a script that changes the color and/or text formatting of a browser's tab--any tab, not just the currently selected one--when a given process completes, so that I can tell, without tabbing back to said tab, if the process is finished or not.
What I'm looking for is the specific bit of code or call to make that accesses the tab's style (or whatever); something where I could go
tabWhereScriptFinishedExecution.style.color("#77ffa5");
tabWhereScriptFinishedExecution.style.fontWeight("bold");
or something. Tab Mix Plus and its different effects on the tabs reflecting various states and whatnot were what got me thinking about this.
I'm using Firefox, and working this into a Greasemonkey script, so I'd like to avoid using JQuery if possible.
As far as I know it is not possible to do the way you are trying to achieve it. You cannot style the tab text. It is part of the browser. Tab Mix Plus you are referring to is a plug in for Firefox.
I've got a couple of cases where I use a textarea to display some source code for database queries. The idea is to allow the user to select all the text in the textarea so they can copy that code and paste it some where else. All is good and well except in IE-{8,9} which are the only two IE browsers I care about.
The selection works fine for one textarea and not for the other. I've racked my brain over this for hours with no luck. I've tried to reproduce this in a tiny code snippet to illustrate the problem but that hasn't worked either.
So to go at it another direction is there a way to disable selecting text from a textarea that is IE specific and doesn't require specific javascript code? I'm not writing any specific code to disable the selection of text in a textarea.
for example if I have this textarea
<textarea>Some Text</textarea>
How might that text be unselectable in IE only? I've also tried selecting the text programatically using jquery, javascript, and DOM api. Which works in all browsers except IE-{8,9}.
Just for example.
$('textarea').select();
I've pondered the idea that some event listeners are not present, but since the IE developer tools sooo amazing I haven't had any luck tracking those down comparing what's listed in Chrome.
I've also reset IE and ensured copy 'drag and drop or copy and paste' is enabled.
I would chalk it up as a browser bug and write my own but since it work in one case and not the other it seems like something happening in the background I'm not seeing.
Yo can't refer to the textarea like this. You must use an id.
<textarea id="foo">Some Text</textarea>
<script type="text/javascript">
$('#foo').select();
</script>
Select by ID works perfectly fine for me:
jsfiddle link
Well as it turns out there was a mixin that was overriding the onselectstart method.
if (typeof self.node.onselectstart !== 'undefined') {
self.node.onselectstart = function() {
return false;
};
}
I have a textarea
<textarea id="id-textarea-readme" wrap="hard"></textarea>
which works realy fine, until someone writes his text in "notepad" and puts it in there via c&p , the words are wrapped correctly but no "extra" linebreaks are made (which is kind of the purpose of "hard")
Is there any workaround to make this work? any JS or a trick to trigger the linebreaks?
The wrap=hard attribute is nonstandard and does not work consistently across browsers. Modify the design so that you do not need to rely on such client-side operations. Textarea elements should be expected to yield actual user input, containing line breaks when user actually hit Enter. If you need to split long lines for further processing, do it server-side.
In my tests, IE wraps even in copy and paste. Firefox, on the other hand, introduces hard line breaks only when it wraps at whitespace but not when it wraps inside a “word”, so that for cols=5, the input 0123456789 (whether direct or copypaste) gets displayed as two lines but sent as one line, whereas 01234 56789 gets sent as two lines. I would expect to find other browsers incompatibilities as well.
the copy & paste issue probably comes from native OS linebreak/return/newline issues.
you could just listen for change or paste on the textarea DOM element and parse with javascript? that'd be my conceptual guess, here's a generic example in jquery:
$("textarea").on("change", function(event){
$this.replace(/\n\r?/g, '\n');
});
I'm having an issue where, periodically, I am unable to type into any input/textareas on Internet Explorer. I'm working primarily with IE9 at the moment.
When I click on an input, the JS click handler (which empties placeholder text) runs, and the active css is applied. However, the cursor does not appear and I can't type. If I tab to an input field, and start typing, everything starts working again.
I have a fair bit of JS running, but no errors running. I suspected TinyMCE had something to do with it, but it also happens when there are no editors on the page, so that doesn't seem to be it either. If you don't have an answer, I'd love an idea of what could be happening here that I could look into more, since I'm a bit stumped.
I eventually solved this. It was a strange and nasty issue with TinyMCE, where TinyMCE was being destroyed while the cursor was inside the main window. Fix was to explicitly focus out before it gets destroyed.
I had a similar issue once with I.E. where I was using .split to make sure the input box was not empty when gaining focus. However, I.E. did not support .split and would crash my js. I had to write my own and it ended up working out. Not sure if this in any way applies to what you are doing, but I thought I would just throw it out there.
Since you have lots of javascript on the page, a likely reason would be either a naming conflict or even more likely a js crash. Traverse your code for the 200th time.
I am part of a team that works on a Java application that, among other things, helps people organize and annotate information from the web. We currently use a Firefox plug-in that attaches a container attribute that contains a document source, which allows dragged text to become cited automatically. This will not always result in getting the source document because only text is transferred when a selection does not cross html tags. e.g.
<p container="http://www.somesite.com/blah.html">this is text from a site</p><p container="http://www.somesite.com/blah.html">this is more text from a site</p>
So if only is text is selected, the html tags are never crossed and the browser thinks the surround tag information and its container attribute would be unwanted; so it ignores it.
So I decided to make a Chrome extension that would exploit some of the nifty features of HTML5 to make any drag from a browser page that is dropped into out Java application include the source document. FYI, Chrome extensions are Javascript based.
The correct for thing to do, it seems, is to register a dragstart event on the document that will allow me to access the content of the drag and also let me inject a meta tag that includes the source document location.
According to the current standard, http://dev.w3.org/html5/spec/Overview.html#the-datatransfer-interface , this should be possible by using the dataTransfer interface.
So, I register the dragstart event that should give me the dataTransfer event information. You can copy and paste this code into Chrome's Javascript console to see it for yourself:
window.addEventListener("dragstart", function(event) {
console.log(event.dataTransfer.types);
console.log(event.dataTransfer.getData("Text")); });
Then select something and drag it. In Chrome, the output is "null" then "undefined". If you paste the same code into Firebug's Javascript console then drag some text that you select, the out put is what you would expect:
DOMStringList { 0="text/_moz_htmlcontext", 1="text/_moz_htmlinfo", 2="text/html", more...}
whatever text was selected
Curiously, one can use setData on the event.dataTransfer to change what is dropped. That part seems to work as expected. Paste this instead into the Chrome Javascript console, then select something and drag it to a text editor or your search box:
window.addEventListener("dragstart", function(event) {
event.dataTransfer.setData("Text","I made this here for you!");
});
It looks like it's broken. :( Does anyone have a workaround or some insight into this issue? I really want this to work in Chrome because I like its extension architecture.
Thanks!
WebKit, and hence Chrome, is quite restrictive on when you can call getData. You're not allowed to do it inside dragstart or dragover. I think this is the canonical bug.
Paste this line before the error line:
event.dataTransfer = event.originalEvent.dataTransfer;
This worked for me.