I stumbled across a weird issue when testing an application on an old chrome version (5.0.3).
So basically I'm using a controller on a directive like:
<div ng-controller="MyController" class="my-directive-with-isolated-scope">
<!-- ... -->
</div>
This seems to be perfectly valid in most recent browsers, however it throws an exception in older versions of Chrome:
Multiple directives [myDirectiveWithIsolatedScope, ngController] asking for isolated scope on:…
Any idea why there's a difference?
[Edit]: Just noticed that this also applies to Firefox.
I would probably say that having a controller directive and another directive sharing an element may be problematic. In this case, you are saying I want each directive to have an isolated scope on the same element. What is your directives purpose? If you moved your directive to a sub element then the problem would go away. Of course this may not answering your question.
Related
Am I allowed to omit the path entirely from a href and start with a question mark?
For example: If my webpage is https://example.com/mycgi, can I have a link of the form bar?
I've tested this on Firefox and the link works as expected - clicking it takes me to https://example.com/mycgi?foo=bar. Will this work the same way on all modern browsers? What is best practice for this type of link?
I've tried searching MDN which usually has a good table of feature and browser version support, but https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#href doesn't have give details about relative link formats.
I usually use href="mycgi?foo=bar", but it means adding a less portable reference to mycgi in the page. I'd prefer not to have to dynamically add mycgi to every reference in the cgi which generates the page.
This is a pure html and browser compatibility question. I am not looking for server or client side tools to modify links.
There should not be any issue with it.
You should be able to write any of those and they should resolve like any other link element. You might wan't to test it out on every major browser. But if you find a browser that doesn't support it i'm pretty sure the browser is not up to spec.
href="?foo=bar"
should resolve to domain.com/currentPath/CurrentPage?foo=bar
href="newPage?foo=bar"
should resolve to domain.com/currentPath/newPage?foo=bar
href=".?foo=bar"
should resolve to domain.com/currentPath/?foo=bar
href="/?foo=bar"
should resolve to domain.com/?foo=bar
etc...
We've recently started using Polymer at work and we like it but we've found that the ShadowDOM polyfill causes serious performance issues in Firefox when used in combination with heavyweight DOM manipulation (we've encountered the issue with the DataTables jQuery plugin but the effect can also be seen by simply having Firebug open).
We can live without that polyfill so we decided to just use the CustomElements and HTMLImports ones. We followed the official guide on building individual polyfills and generated the minified JS files but when we use them both we consistently get this error:
"TypeError: CustomElements.parser is undefined"
When we use platform.js we do not get this error. I've even tried generating older versions of the polyfills to see if it is a recent issue to no avail.
When we dug into the code it seems the bootstrap function of CustomElements is calling CustomElements.parser.parse() - parser is added to CustomElements shortly before but between these two things something is resetting CustomElements and it loses its parser.
I've managed to replicate the problem in a small test case. I can't put it on JSFiddle as it requires HTML imports and I got CORS errors so I've had to host it on my shared server (please be gentle!). You will need to open it in Firefox to see the error (you also see the error in Chrome but it doesn't need the polyfill so the custom element still shows up):
http://lilchef.co.uk/polymer-polyfill-bug.html
By comparison here is the exact same test case but using platform.js instead. This works but includes the problematic ShadowDOM polyfill (if you open Firebug whilst running it you should experience the slowdown):
http://lilchef.co.uk/polymer-polyfill-platform.html
We should be able to use these two polyfills without having to use ShadowDOM shouldn't we? Has anyone else encountered this issue?
I am not able to run the script using WebDriver across different Browsers.For IE its working fine.
Firstly I automated an application for IE.then I tried to run the same script in Chrome or FireFox.
Now on Chrome and FireFox some of the elements are not getting recognized by the WebDriver.
1. How can this be resoled?
2. Is there any solution for this so that I can run the same script on different browsers irrespective of the Browsers?
Please suggest.
Without seeing the page it would be hard to tell, it depends on your situation, normally there is one selector that will work across your browsers but its technically possible for your development team to be using completely different element names ids etc etc depending on browser (or even completely different pages), it would be crazy for them to be doing it on purpose but it is possible so you will find people may be unable to help without more information.
Typically css selectors are the most robust selector across browsers while xpath is the most flakey. post some code both of your test and pages and can probably help further
Sometimes, the locator you are using will work in one browser , but not in other browsers. Try using different locators such that it gets executed in all the three browsers.
I'm having a Chrome only issue when adding anchor tags for internal links inside an HTML widget. This may sound quite unimportant but it's quite annoying for myself and many users.
When a page is loaded, if the links are middle-clicked or Ctrl-clicked the 1st time, they only open in a new tab/window like they should, but the 2nd time they act as though they were left clicked and use the same tab/window. For some reason this problem doesn't happen when I use Hyperlink or Anchor widgets. It also isn't an issue in Firefox or IE8.
I've verified that the final HTML of the Hyperlinks and my manually scripted tags are exactly the same. I applied the same styles to the HTML widget to do this. I even tried creating a Hyperlink and calling toString() to generate the HTML, but the bug still occurs.
Does anybody know why this could be happening or have any ideas of how to remedy it? This is a situation where I can't use Widgets so I need to create the tag HTML manually. I'm not a GWT expert, but I don't understand how the compiled code be handling the Hyperlink and Anchor widgets differently than the ones inside the HTML widgets. Any incite into this could be helpful.
I'd be interested in knowing if anybody else could reproduce this as well. I'm running Chrome 23.0.1271.97 and GWT-2.5.0. I know this happens in older versions of Chrome and GWT because it's been a problem for a while, at least since GWT-2.4.
Uninteresting nuances:
If there are two different links inside the same HTML, they bug will happen independently. Meaning that you can middle-click each one, and they will both work correctly, just not the 2nd time. Refreshing the page also resets them so the bug won't happen on the next middle-click. I also found that if the same link is twice contained in the HTML widget, they actually wont work independently. Meaning middle-clicking one will cause the other to incorrectly handle it's 1st middle click.
Just finished debugging this. It is not a GWT issue but a Chrome issue.
I created a bug report: http://code.google.com/p/chromium/issues/detail?id=177502
You can reproduce using this simple HTML page:<!DOCTYPE html>
LOCAL
In IE, with Flex application embedded, changing page location with JS like that:
document.location.href = "#someFragmentIdentifier";
causes change of page title to "#someFragmentIdentifier". I've read that the cause of that was supposed to be integration of Flex application with browser navigation, so I disabled it at the Flex compiler properties screen, however it didn't fix anything. Could anybody help me by pointing some working solution to this unwanted behavior.
Thanks.
PS: You can easily reproduce that by starting your Flex application and changing current URL by hand so it contains fragment identifier and then refreshing the page.
We've run into this using various ajax toolkits, including MS's.
It is not limited to Flex, flash, or any Adobe tech. It is purely a browser issue.
Unfortunately, the ONLY workaround we've found that was worthwhile involved "changing the title with javascript".
There's a bug in Adobe's bug tracker with various workarounds. I guess one of them should work...
http://bugs.adobe.com/jira/browse/FP-240