7

We have a DotNetNuke module running in an instance of DotNetNuke 5.4.4, installed on "Server A", a Windows Server 2008 R2 Standard machine with IIS 6.1 and Internet Explorer 11.

We're accessing our DotNetNuke module from "Server B", running Windows Server 2008 Standard, with Internet Explorer 9.

The issue happens when we click an anchor html element that has an onclick attribute, while accessing our module on Server B.

The anchor with the onclick is like:

<a onclick='OpenWindow("/DotNetNuke/DesktopModules/Module/View.aspx?dt=%c2%b2%c2");return false;' 
   href="http://000.00.0.0/DotNetNuke/DesktopModules/Module/View.aspx?dt=%c2%b2%c2"
   target='_blank'
   jQuery1431968126278="42">Doc name (SSN-SS-SSNN)</a>

And the OpenWindow function is like this

function OpenWindow(url) {
  window.open(url, '', 'top=15,scrollbars=yes,menubar=no,height=800,width=800,resizable=yes,toolbar=no,location=no,status=no');
}

As you can see we have an anchor element, with an onclick attribute, where it is supposed to call the OpenWindow javascript function, then return false, so the default action for clicking an anchor (browse to the href) does not happen.

When we click this link though (ONLY on server B), we get no popup window, no breakpoints in the OpenWindow function are hit, and the browser navigates to the href by opening a new tab (View.aspx). This suggests to me that the OpenWindow function referenced by the onclick attribute is not even running for some reason, even though it is on the anchor element, and works on any other server.

What I've tried

I compared the security settings, web.config files, and DotNetNuke settings between the Server A DotNetNuke and my local developer DotNetNuke instances, and found no differences in setup.

I compared the Server B Internet Explorer security settings to my security settings, and found no differences in setup.

On the advice of comments on this question, I tried changing the anchor tag to a span tag instead (removed href and target attributes), and I am seeing the same behavior. It works on Server A and Dev, but doesn't do anything on Server B now. I think the core issue is that either the onclick attribute is not being recognized, or is being blocked somehow.

I've now gone further and changed most of the <a>...</a> tags into <span>...</span> tags, with specific classes, that I then attach jQuery(...).live('click', ...) handlers to (using jQuery 1.4.2). That is allowing the clicks to work, but I still haven't resolved why the onclick attribute is being ignored.

What's weird..

If I open the developer tools (IE9), then click the "Edit" button to turn edit mode on and off again, all of the onclick attributes on anchor tags and img tags start working correctly, until I reload the page.

If I edit the onclick handler in any way manually through the developer tools, like say removing the return false; from the onclick handler, it will work, but if I put the return false; back to make it like I never changed anything, it stops working again.

What I'm trying to figure out

I am hitting a wall with what to check to figure out this issue. I can't reproduce it on my developer machine, and it works on Server A as well, so the code is working perfectly fine. I'm thinking there must be a setting that I am overlooking somewhere, but where? I have no idea what else to check at this point, and I'm looking for ideas.

Zack
  • 2,789
  • 33
  • 60
  • Does it have to be ` – Yuriy Galanter May 18 '15 at 18:44
  • Are there any errors in the console when you load the page or click the link on server B? Also have you tried manually running OpenWindow() from the console on server B? It's possible that either OpenWindow() is not being defined (for example there could be an error above it that stops execution before the definition is run), or it is being defined more than once, and the version that is running is not the one you are expecting. – Matthew de Nobrega May 18 '15 at 19:18
  • @YuriyGalanter It doesn't have to be an anchor I suppose. Is there any reason you suspect that a span would allow the onclick to work instead of an anchor? – Zack May 18 '15 at 19:30
  • @MatthewdeNobrega The only error in the console is `SEC7115: :visited and :link styles can only differ by color. Some styles were not applied to :visited` which shows up on Server A, Server B, and Dev. Even with this error, the anchor still works on A and Dev, but not on B. – Zack May 18 '15 at 19:33
  • @MatthewdeNobrega I did run the OpenWindow function, by copy-pasting the onclick from the anchor into the console, and it works when I do that, and hits the breakpoints. – Zack May 18 '15 at 19:33
  • @Zack I have encountered that before that href (especially in IE) tends to behave unpredictable (or at least following its own prediction). Since you don't need actual `href` functionality - `span/onclick` is a cleaner way to do this and a way you fully control – Yuriy Galanter May 18 '15 at 19:43
  • Is it Internet Explorer Enhanced Security Configuration? http://blogs.technet.com/b/chenley/archive/2011/03/10/how-to-turn-off-ie-esc.aspx - I never browse using IE on a Server, it's somehow always locked down. Something usually goes wrong like this! – bgs264 May 21 '15 at 11:22
  • @bgs264 I just checked and ESC is Off for Administrators and Users. – Zack May 21 '15 at 14:40
  • Could it be the Pop-up Blocker (Internet Options > Privacy)? – DigitalDan May 21 '15 at 16:02
  • @TheGermanOne The Pop-up Blocker is off on the Privacy tab. The Security tab in the Internet Options dialog shows that the site is in the Trusted sites zone, with Medium-low as the Security level for the zone. Enable Protected Mode is also set to off. – Zack May 21 '15 at 16:35
  • are you really using IE9 to load server B and IE11 to load the others? could be an ie9 thing. – dandavis May 26 '15 at 23:37
  • Does it happen in firefox and chrome as well? Do they fire error messages? – loli May 27 '15 at 14:11
  • @dandavis We are using IE9 on server B and IE11 on server A and in dev. I did think it could be a "thing" about IE9 but what that thing is... I have no clue. – Zack May 27 '15 at 17:04
  • @loli We don't use ff or chrome because the old version of DotNetNuke that we are using does not look right in the newer browsers. We actually have to run IE in compatibility mode to make DNN look right in IE. By "Look right" i mean that the entire site navigation bar and all the elements are out of place, and the site looks like a mess. – Zack May 27 '15 at 17:06
  • is your anchor created dynamically? – loli May 27 '15 at 17:15
  • Yes, I think it is considered dynamically created. We have an ascx control called DocumentRowTemplate, which is registered on the Details page, and then included inside a ` – Zack May 27 '15 at 17:25
  • I read in another so question that IE does not bind click event handlers automatically when the onclick attribute of an element is changed dynamically because they're not DOM attributes – loli May 27 '15 at 19:06
  • @loli Do you have a reference for the information or an example? I don't think that is the case because it has worked fine for the 2 1/2 years I've been working on it, and it still works just fine on one PC on their network, just when they access the site from another PC, the onclick acts like it's not there. – Zack May 28 '15 at 14:18
  • read it there : http://stackoverflow.com/questions/771721/ie-not-allowing-onclick-event-on-dynamically-created-dom-a-element – loli May 28 '15 at 14:21

5 Answers5

1

I don't have an exact answer, but I can give you the general idea of what is happening and why.

The two servers are not getting identical content -- perhaps they are pointed at different CDNs, perhaps one has an old file of a JavaScript file somewhere -- you'll have to walk through them one by one.

Something, somewhere, is applying an onclick handler to all of your anchor tags.

At first I thought it was something attached to the body element and targeting your links, but I ruled that out. The fact you can edit the HTML and save it and then the link works means you are detaching whatever was attached to that link element.

I would:

  • Save the entire web page from Site A
  • Save the entire web page from Site B
  • Run a diff tool against the two directories.
Jeremy J Starcher
  • 23,369
  • 6
  • 54
  • 74
  • I actually did that, and other than the ClientID values generated for controls between the two, they are identical. – Zack May 22 '15 at 13:52
0

Have you tried to call window.open directly from the onclick attribute? It could be that the function is not loaded at the time the link is clicked, so it produce an error, so return false is not called, and the link proceed with its default behaviour (in this case open a tab).

If this is the case, look at the loading order of that function, or try placing it in a different part of your code (maybe within the onload event).

Check if you're showing JS errors in your Internet Options.

  • I think I might have mentioned that I can copy+paste the onclick attribute's value into the console, and it runs perfectly from there, and opens the window. I know the function is loaded at the time the link is clicked because if it was not, the window would not be opening when running the script from the console. – Zack May 27 '15 at 17:13
  • Also, there are no errors showing up in the console in IE at all besides one about trying to apply styles to a pseudo-element that can't be applied. – Zack May 28 '15 at 14:21
0

It might be a bit childish, but since you are opening a window as a Pop Up there can be issue that the URL from the site might be blocked from the browser. It should work at all times if you just replace

window.open(url, '', 'top=15,scrollbars=yes,menubar=no,height=800,width=800,resizable=yes,toolbar=no,location=no,status=no');

with

window.open(url);
IBAD GORE
  • 403
  • 2
  • 5
  • Where would I be able to find the URL blocking you are describing? The URLs for the new windows are in the same site (hosted in IIS on the intranet), so I think if we can get to the main site, the new windows should not be blocked in the way you are describing. – Zack May 27 '15 at 17:15
  • Check this link, this gives insight about what I think is the issue : http://stackoverflow.com/questions/9514698/bypass-popup-blocker-on-window-open-when-jquery-event-preventdefault-is-set – IBAD GORE May 28 '15 at 08:25
0

Have you tried modifying your tag to:

<a href='javascript:MyFunction(this);' data-url='YourUrl'>Name</a>

MyFunction:  function(obj) {

var element = $(obj);
window.open(element.data("YourUrl"));
}

Note that if the user's browser is configured to open Windows as tabs, there is not a workaround. target="_blank" is the best way that I know of to achieve this and enforcing browser behavior via GP.

Anthony Mason
  • 165
  • 1
  • 12
  • Putting javascript in the href is bad according to this highly upvoted answer on another question. http://stackoverflow.com/a/11348403/1804496 I have however used jQuery to attach click handlers to `...` elements, and they work now. I just still want to know why the onclick does not fire the javascript function. If I have time I can try out your specific suggestion of putting the javascript into the href, but I don't think it is a valid solution. – Zack May 27 '15 at 17:11
0

Sounds like it's something not in the scope of the code you have provided. You mentioned opening the IE9 dev-tools makes it work, I suggest try adding console -polyfill, something like:

if(typeof(console)=="undefined") {
  var console = {
    log : function() {},
    error : function() {},
    debug : function() {}
  };
}

Just in case some of your code is outputting things into the console and the JS code stops working after that event. Could be some external library, which after loading starts outputting things to the console - that might work differently on different servers because of caching settings and/or network latency.

NOTE: to test this properly, remember to add this into a SCRIPT tag before you load any JS code or import any external library.

Tero Tolonen
  • 4,144
  • 4
  • 27
  • 32
  • I just looked through the code and we have no console.log, console.error or console.debug calls in any of the javascript we write ourselves. The only occurrence was some console.log calls that are in the jQuery library but they are wrapped with checks to make sure that console.log is defined. – Zack May 27 '15 at 17:18
  • Also, just opening the dev tools is not sufficient, I have to turn on edit mode and then turn it off again for it to start working correctly. – Zack May 27 '15 at 17:19
  • Ok, that OpenWindow -code is something used about 10+ years ago, perhaps you might achieve better results using some other approach, pop-up blockers can block that kind of code in some cases. – Tero Tolonen May 27 '15 at 17:21
  • Perhaps someone has enabled the pop-blocker to that server btw. hard to say... http://answers.microsoft.com/en-us/ie/forum/ie9-windows_7/ie-9-pop-up-blocker-where-is-it/ee81c7f8-2b65-e011-8dfc-68b599b31bf5 – Tero Tolonen May 27 '15 at 17:26
  • I mentioned in comments on the question that the pop-up blocker is disabled on both servers and in dev. – Zack May 27 '15 at 17:27
  • "pop-up blockers can block that kind of code in some cases." would it make it so that it seems like the onclick that uses the code basically doesn't exist? What I'm seeing is that the onclick handler just doesn't fire at all. No breakpoints are hit in the OpenWindow function on Server B. I think if a pop-up blocker was doing it, it would at least notify you that a pop-up was blocked, right? – Zack May 27 '15 at 17:29
  • Test if you can re-produce this problem with different machines running the same OS, like test with BrowserStack or similar - if it still does not work, check the charset and MIME -types of the server responses for the pages and scripts, can't think anything else would go wrong, if even that - the document mode of IE can sometimes, but the requests should be similar? – Tero Tolonen May 27 '15 at 17:33