I am writing a Chrome Extention where I need to store and restore the user's highlighted selection. The stored information will be stored on my server. I am wondering how I would do this?
I looked into using Range, but am unsure if this is the right way since the example below only worked in FireFox.
I found this example but it only works in FireFox :(
I think the technique on that page probably does work in Chrome: there's no reason why it shouldn't. When I save the selection and reload, I see the selection restore and then quickly disappear, so I suspect something in the page (possibly the ads) is destroying the selection somehow.
If you can't get that to work, you could try the serializer module of my Rangy library, although it's probably overkill for just Chrome.
In general, using the browser's Selection and Range APIs is definitely the way to go. They are now standardized and universally supported (with some quirks and bugs, naturally) in current browsers.
Related
For example, when I'm pasting whole Stackoverflow page to conteneditable in Chrome, it preserves most of its formatting. When I do the same in Firefox part of the data (styles) is lost. The same is true for IE.
Probably, it depends on the different internal handling of Copy&Paste mechanism in different browsers and we cannot do anything about it.
Nevertheless, maybe there is some clever hack around it.
Thanks.
I have created lots of buttons for a large number of pages (usually 5-10 in a row at the bottom of each page inside a table cell) using input type="button" name="..." value="..." onclick="some javascript event handler" etc, basically to link to other pages of the same group. All these pages are ultimately linked from an iframe tag on a single page. The buttons are working fine offline on my PC at least. But, now I've suddenly realized that I haven't used any 'form' tag for these buttons.
So my question is, is this 'form' tag really necessary? Will there by any problem after I upload? I would prefer not to add the form tag now to so many pages if it's not really necessary, because that's going to be a real drag. But, I don't want to suffer afterwards either.
No it is not necessary as long as you are not doing any Get/Post and grouping form elements together. They should work completely fine without a form tag.
There are two issues to be concerened with:
Is it valid HTML?
Turns out that it is valid HTML (see Is <input> well formed without a <form>?), so you are on the safe side here.
Will all common browsers accept it?
After googling around I haven't seen any information on problems wih this use of Input tags. That suggests that all common browsers accept this valid HTML (as they should). When developing any website that is accessible to the general public I would always do a manual cross-browser check to discover any abnormalities certain browsers may habe with my site.
Problem is that you most likely won't be able to tell from looking at your server logs whether certain browsers have a problem with your HTML. It may just not work on IE 6 and you would never be able to find unless a disgruntled customer calls up and informs you.
If this is a generally accessible website get some stats on the most commonly used browsers, decide which ones you want to support, and verify that the website is behaving properly on thiee browsers. This is a pain in the ass, but there is no way I know of to get around that. Browsers may not react to valid HTML properly.
As a rule of thumb, Firefox, Chrome, and Safari unsually behave well, and because of auto-updates most people will have a very recent version installed. If the latest version of the browser works I wouldn't be too concerned that users with some older version will have trouble.
The real test is always Internet Explorer. While version 8 and 9 are pretty standards-compliant, IE 7 certainly needs checking. IE 6 is the worst offender for unusual behavior. It was introduced in 2002, but today still 6% of the population use it! Most of this comes from cracked copies of Windows XP in China, but it is also used quite a lot in corporate networks, where OS and browsers are centrally deployed, and administrators have not managed to progress since early 2000.
In conclusion: Your code is unusual but ok, test it manually on the browsers you expect.
Im trying to use ranges to check if the mouse is over an url, but I dont know how to tell the range that expand to get the full url, not just each word in it.
Here is an example to show the problem: jsFiddle
I will use this code in an editable iframe. If an user write an url, I want to give him the possibility to open it although it isn't an anchor element but plain text. Im not sure if can achieve that, but i want to try it.
One problem is that the expand() method of Range is non-standard and only supported in WebKit. Another is that document.caretRangeFromPoint() is also WebKit-only. Yet another is that there is no way of specifying a regular expression to match when identifying a word.
One option is the new TextRange module of my Rangy library, which works in all major browsers and provides a more flexible expand() method of ranges. There's also a work-in-progress position module that provides a cross-browser implementation of document.caretRangeFromPoint() (which is standardized as document.caretPositionFromPoint()).
Unfortunately, the position module is flaky in Firefox, but I intend to fix it soon. Also, the following demo doesn't work in IE at the moment, for reasons I think related to jsFiddle. So overall this is far from satisfactory, but may give you some ideas.
Live demo: http://jsfiddle.net/q3AtL/5/
I've got this example page where I'm trying to put the wmode of every youtube element inside the page to "transparent".
To do it I need to get all the "object > params" and "embed" tags in the page.
The page I link you works like charm in all the browser except for IE6 (haven't cheked the other IEs yet).
With IE6 I can't catch the "params" since document.getElementsByTagName('param') returns an empty object, but this doesn't happen with the "embed"!
It won't work with document.getElementsByTagName('object') as well
Here is the page http://dl.dropbox.com/u/4064417/provaJs.html
Any suggestion why it's not returning just the "param" tags?
Thank you in advance!
I recall some issue with <param/> tags and getElementsByTagName, but it's ages that I don't code in IE6. Instead of querying from document, trying to get the params calling getElementsByTagName from the <object /> itself and see if it helps:
var objects = document.getElementsByTagName("object");
for (var i = 0, object; object = objects[i++];) {
var params = object.getElementsByTagName("param");
alert(params.length);
}
I understand that you would like to keep your app backwards compatible, but this exercise runs counter-intuitive to the general direction of the industry and its efforts to put IE6 down to rest (even google has dropped support for IE6). Your time might be better invested if you focus on building a better web experience for pseudo-modern browsers instead of worrying about the legacy ones.
Food for thought - maybe use a browser detection script and encourage your users to upgrade so that they can experience your site in all of its modern glory :)
All that being said, ZER0's suggestion is dead-on. Find the "object" tags in the page, and then iterate through its children until you find the tag you're looking for. If you can't seem to grab the object tags with getElementsByTagName, you may very well have to iterate through the document.body.childNodes nodelist, checking for the typeof(N) or N.NodeName along the way.
If you must support browsers as old IE6, I would strongly recommend using a library such as jQuery rather than trying to access the DOM directly.
IE6 has a massive number of bugs and quirks that can break even the simplest and most innocuous of Javascript code. jQuery goes to great lengths to abstract these browser bugs and deficiencies away from the developer, allowing you to write code that works on all browsers.
For example rather than using document.getElementsByTagName('object'), you can use the jQuery code $('object'), which will give you the same end result, but will work around any bugs in whichever browser your end user is running.
jQuery does a whole lot more than just hide the browser bugs, of course, but if you're working with IE6, that alone is a good enough reason to use it.
(other libraries are of course available if you really don't like jQuery for some reason)
I have a site with anchor navigation (like gmail, when the anchor value changes a new content for a page is loaded with ajax). In Firefox, when I change the anchor (with js or with a page) a new item in the history is created and works perfectly. But in IE6 it doesn't stores this new item and the back button doesn't work as expected.
Is there anyway to add this new item using javascript?
This is possible because gmail does it but I don't know how it does it.
I've done a lot of work with history and using the hash. Almost all of the existing history plugins have some sort of gap in them. The one I've used that's pretty close to perfect is this one which is a jQuery plugin:
http://www.mikage.to/jquery/jquery.history.js
It was updated in March of this year handles IE 8 issues and it also deals with IE6 pretty successfully. One thing I've noticed is that IE really hates having ? in the hash after the #. It stops properly handling the hash when the ? is present. Even this one I think needs a little patch for the ?, I really need to send that along to Mikage. The way to handle this is instead of using location.hash in the plugin when referencing the hash, use this function:
function getHash(loc) {
loc = loc.toString();
if (loc.indexOf("#") != -1)
return loc.substring(loc.indexOf("#"));
else return "";
}
So in those spots where you need the hash, pass location the to function...
getHash(location)
...instead of using location.href. But note that for IE, because it's using the iframe, you want to use iframe.location instead.
getHash(iframe.location)
Yahoo's Bug
You can see that Yahoo doesn't gracefully handle ?'s in IE when looking at this URL:
http://developer.yahoo.com/yui/examples/history/history-tabview.html#tabview=tab1?7236471234
It should just ignore the non-existent module, (which it does for other names which have no ?'s in them). But it raises a JavaScript error when a ? is in the URL.
(I will extend this list in a moment)
Really Simply History
Frankly, it's primary issue seems to be it's gone dormant. I've experienced this issue and just didn't want to dig through it:
Also, even though no changes appear to
take place on the page while I travel
backward through the history, the back
functionality will return once I hit
the pages that I had been navigating
before the one using RSH. So, if I
clicked on four links in the RSH page,
back functionality will return after
I have clicked on the back button four
times. I hope that makes sense.
I think you may have a different problem. IE6 certainly handles # links in history as it should for me on any given test page, so I believe either you have broken this in some way or you have a bug with your particular version of IE.
I suggest you try a few different copies and versions of IE6 on other machines to rule out the latter, and then try simplifying your code and rebuilding it to see if and when the problem appears. Turning off JS may (html depending) be a fast way to test this.
If all else fails I suggest you look at Really Simple History which (last time I checked) solves almost all JS/history problems you can throw at it.
Yahoo has a history manager too.