So if you are any sort of clg fan, you'll occasionally visit azubu.tv to watch them. If you go into the chat, using chrome, you can't change your text color. The reason is in line 689 of the chat js. (it's best to pop it out since it's in an iframe). There is an extra = in the comparison that works in firefox but not chrome.
I did not code this site. However, is there anyway to use a chrome plugin to permafix that function? I've already sent out a code update request to the admin -- a month ago. I've been just opening up the javascript console to do it manually but I'd like to help others.
I isn't expected people to develop extensions (or plugins) to fix web pages' .js, because it would take a lot of effort in reverse engineering and development, and the extension will become obsolete as soon the server administrator fixes his own js.
Extensions can do it, but are a very odd way to do that.
I don't know who voted you down without a comment; it's not the way we used to do it here.
Related
I want to add a button to my visual C++ form that will open with a specific browser. So far for links I've been using:
System::Diagnostics::Process::Start("UrlHere")
Which, as standard, opens with whatever your default browser is.
I'm wondering what the process would be to force the URL to open with a specific browser and if it's possible without the use of ShellExecute?
Edit - You are correct, this is C++/CLI. Removed the C++ Tag.
Edit Edit - Apologies if it came across as misleading. Some slight elaboration;
The buttons will launch to application URL's, some of which can only be used in Internet Explorer, others that CAN (and should) be used in Chrome. This is why I need to avoid using the default browser and have different buttons using different browsers when launching URLs
Before answering the 'how', I'd like to ask the question "should you be implementing this?"
By not launching the user's default browser, you are subverting the user's decision.
Perhaps the user prefers a particular interface, and is willing to live with the incorrect renderings that come with it.
Perhaps the user has a browser addon that they really need, such as a screen reader for the blind.
You are requiring additional software installed that the user may or may not want.
Perhaps the user doesn't want Chrome. Perhaps the user prefers FireFox.
You are saying that you know which browser is best, now and forever.
What if the next version of IE makes it work with the sites that are currently Chrome-only? What if the next version of Chrome fixes the sites that are currently IE-only?
What if the site changes so that it works in more browsers?
Do you go back and release a new version of your software that changes the browser for particular sites?
You're trying to solve a problem that may already be fixed.
Both Chrome and Firefox support a addon that will render a tab using the IE engine. It can be set to automatically activate when certain URLs are seen.
Perhaps there is a browser that already works with all your sites, that you don't know about.
Therefore, my recommendation is no, do not do this. The user has decided which browser they want to use, respect that decision and use the default browser.
That said, here's how you would do it: You could use the CreateProcess method, but you're in managed-land, so you might as well use it. Use the Process class to launch the new process for you.
Process^ browserProcess = gcnew Process();
browserProcess->StartInfo->UseShellExecute = false;
browserProcess->StartInfo->FileName = "C:\\Program Files (x86)\\Internet Explorer\\iexplore.exe";
browserProcess->StartInfo->Arguments = "http://www.google.com";
browserProcess->Start();
For my company I've created a RSS reader extension for our internal blog. The reason why I've build my own is irrelevant, I know there are many existings extensions. Suffice to say that the blog is completely sealed of from the outside. And let's not forget that it's simply fun to try new things like this :)
The extensions works almost perfectly. It shows a nice popup with the latest 10 posts and it shows a counter if new posts have been added to the blog.
However, since most of my collegaes are webdevelopers like myself, some of them use firefox ( the extension is being ported by an automated script for use in FF ) and have the "clear history on browser close" option enabled. This does however delete the localstorage as well. I know that this setting is the issue and not the porting because my collegae that do not have the option selected don't experience any of these problems.
I use localStorage to remember which posts have been read and which haven't. So for these people the result is that every browser restart the extensions says there are 10 new items regardless of any items they may or may not have read.
I've thought of a way to work around this issue by using a MySQL database through php and ajax. But I'd still need to reliably be able to store a userId or something to personalize the read/unread list.
There must be an easier and better way. I know many extensions with similar functionality that do not have this issue but I've got no idea how and can't find anything about it.
Do any of you have an idea ?
Thanks!
I just tried my own Chrome extension using chrome.storage.sync API.
The storage won't be deleted if you clear all the history and local cache.
I've only built Chrome extensions, not FF ones, but if you have access to the file system, you can store the data in a simple text file. To be honest, I'd blame the developers for clearing their history. ;)
How do I create an always-present sidebar in a Chrome browser extension? Do I have to inject something into each page the user views? That seems weird because it would disappear every time the user navigates to a new page. Also, I'd be worried about my code and HTML interfering with the page and I can't possibly test every page on the net to be sure it works everywhere.
It looks like there was an API for this that was just removed? Is this feature dead for good or are there any plans to bring it back?
You have to inject HTML into every page. There was an experimental Sidebar API for a while but it was never developed to state that the Chromium team was happy with. They are still keeping the issue open but it is not currently being developed. You should star the issue if you wish to get updates on it's progress.
Update:
The feature is removed and there is no further development on it.
Quoting from their site:
We will not be proceeding with this feature request. We recognize that there is a significant number of you who will be disappointed with this decision, evidenced in part by the many stars on this issue. We debated it extensively, both inside the team and with members of the community. In the end we decided that the WontFix resolution was more in keeping with Chrome's core value of simplicity.
I was thinking to add meta tag always in all the websites.
That will trigger google chorme frame to load for users who already installed. I can see the benefits but is there any concerns or facts that I should know before I do that?
Testing in google chrome is enough or testing in google chrome frame explicitly required?
Thanks
Note: please do not mention current know problems "print" and "download" issue. I'm sure those will get fixed soon :)
The only argument against chrome frame that I have seen so far is Microsoft's - "Google Chrome Frame running as a plugin has doubled the attach area for malware and malicious scripts."
Also, you may run into problems with frames. If you have chrome frame on your page and someone has that page iframed on their site you may run into some problems. More info:
http://groups.google.com/group/google-chrome-frame/browse_thread/thread/d5ffe442658bc60e/e6d7a4c1c179c931?lnk=gst&q=iframe
You should only need to test in Chrome Frame for (X)HTML, CSS, and JavaScript...basic stuff. If you are using AJAX (while trying not to break the back button), worried about caching, cookies (accessed via javascript), or other potentially browser-specific browser interactions I suggest testing on the IE+CF platform...at least until the CF team announces 100% interoperability between CF and IE.
Check out the CF Google group for more issues.
Are there any concerns or facts you should know? Yes: Not everyone has Google Chrome Frame installed.
You are adding a new user agent that you will need to test and debug against, without removing the need to test and debug the user experience for other browsers (notably plain IE by itself).
If you don't make the IE user experience equivalent to the Google Chrome experience, then you are alienating a significant percentage of users. Depending on your website and its expected users, the impact of this may range from undesirable to unacceptable. If you do make the user experience equivalent, then there is no point in adding the meta tag.
I'm tyring to get phonegap up and running on blackberry storm (9530 simulator). I had been testing my webapp from withing BB's built in browser, and it was looking ok, but then it totally bit once I tried to look at the some code from within phonegap, even though I was pointing phonegap to the same url (I hadn't yet gotten to the point of running code locally on the device).
I tried a test case on google and got similiar results. see below. I suspect that I'm missing something basic here. I would have expect both images to be nearly identical.
Browser
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530WebGoogle.jpg
Phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530PgGoogle.jpg
[Update]
To shed some light on what is happening, I ran the browser and the embedded browser (phonegap) against the W3 mobile web acid test: http://www.w3.org/2008/06/mobile-test/
I definitely notice differences between the two, but I don't yet know the 'why' and the 'how-to-address'.
Acid via built-in browser
(source: eleganttechnologies.com)
BTW - I ran this earlier today and got a couple more green square than just now.
Acid via browser embedded into phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBb9530PgAcid.jpg
Disclaimer: I don't know anything about phonegap, but have a pretty good theory. By default the embedded browser control on BlackBerry uses an older version of the rendering engine than the BlackBerry browser itself does.
At the BlackBerry developer conference last year, a talk was given about this, and there's an undocumented option to use the newer rendering engine. \
The option ID is 17000 (yes, a magic number, which could change, use at your own risk etc), and should be set to true. Not sure how you'd pass this option through phonegap (I'm not familiar with the toolkit) but using the BlackBerry APIs it's something like:
BrowserContent content;
...
content.getRenderingOptions().setProperty(RenderingOptions.CORE_OPTIONS_GUID, 17000, true);
I don't know the specifics of the browsers you are using, but I do know that most of the big sites will detect your OS + browser combination to decide what HTML to show you.
If Google is seeing a different user agent, you might get a generic mobile version of the HTML instead os the Blackberry specific HTML you get for the built in browser.
If you have access to a web server, try hitting it with both browser setups and see if there is any difference in the log file. That might tell you something interesting.
As we can see in your Acid tests...
One browser (the built-in one) is reporting correctly as a BlackBerry9530, and the other (phonegap) is not presenting the user-agent ["Testing with ."].
In this case, Google is providing you with the default view of their homepage, whereas when you are reporting yourself as a BlackBerry device, you will get the BlackBerry specific rendering.
By the sounds of things, using phonegap is removing the default user-agent (most probably because it's not recognising your device). As phonegap is open-source, the best bet is to get in there, and debug it and find out what happens with the user-agent when the http requests leave the device and track it back from there.
Maybe one browser has capabilities that another one does not?
Hm. By looking at the screenshot I would say that the second page is probably missing some resources. It may be missing some images, scripts and the CSS files, which would explain different l&f. Knowing how Blackberry Browser Field API works, I would guess that the implementation that uses the BrowserField was not done correctly. Just my guess. In addition to that, when the browser field is initialized the caller needs to configure it properly by enabling the appropriate browser features - scripts, styles etc. Again, the API is done in a very weird way, I have gotten myself into this trap once. When setting the options, you cannot just create one mask (like CSS | WML | SCRIPT) and make one call. Options are numeric and, I believe, non-overlapping - but you still need to call the API for setting each option independently.
Also the way asynchronous loading of the resources for BrowserField takes time to understand.
Just my $0.02.