jQuery code working in Chrome but not in IE

Question

I am implementing this code in the RSA Archer Platform.

Its working perfectly in Chrome but not in IE9.

function hideDeleteButton(){
  var elId = "master_DefaultContent_rts_s2487_f6881srvgrid_ctl00";
  var el = document.getElementById(elId);
  var className = "GridRemoveImage";
  if (el != null) { 
    var lst = el.getElementsByClassName(className);
    for (var i = 0; i < lst.length; ++i) { 
      lst[i].style.display = 'none';
    }
  }
}

$(window).bind("load", function(){
   hideDeleteButton();
});

document.load = hideDeleteButton();

Answer 1

Since you tagged the question with jquery I wrote this jquery code equivalent to the javascript code you provided.

$(window).load(function() {
    $("#master_DefaultContent_rts_s2487_f6881srvgrid_ctl00").find(".GridRemoveImage").hide();
});

You dont have to loop through each element to change the visibility. This code will have the browser compatibility too.

Answer 2

This new function should do the job:

function hidedeletebutton() { 
    $('#master_DefaultContent_rts_s2487_f6881srvgrid_ctl00 .GridRemoveImage').each(function() {
        $(this).hide();
    });
}

it does the same, only shorter and with jQuery

Answer 3

This question has a couple of fundamental aspects I would like to cover:

Bad design

The fact that you have to hide "Delete" button tells me that you Archer application is not designed right. You need to control access to the records via roles and records permission configuration, but not with Custom Object code. What if I activate the Delete button manually using the developer tools and will delete the record? Do you want to be responsible for this as a developer? I recommend you to make two steps back and redesign access controls in your application. The question you asked should be me asked at first place.

RSA Archer Platform

All jQuery related answers don't account for the following factors:

• This is a code for the Custom Object - special type of object used in RSA Archer platform.
• Archer platform generates JavaScript-rich web-pages. So I recommend you not to overload document related functions unless there is a real need to do so.
• Custom object code is executed when the form is loaded, in the most cases there is no need to override "document.load" event handler.

This is an example of code you can use for IE8-IE11, FireFox, Chrome and Opera:

<script type="text/javascript">
    document.getElementById("master_btnDelete").style.display = "none";
</script>

Why this works? Because JavaScript code stored in the Custom Objects in Archer will be executed once it is loaded as a part of the form itself.

IE Specific Behavior

You actually may need to override window load event in case if the given archer application has a pop-up dialog windows used to populate value lists of cross-references. In this case tool bar buttons including "Delete" button might be restored after each pop-up window being displayed. In this case you have to use a similar code:

<script type="text/javascript">
    // function that will hide the Delete button
    function doLoad() {
        alert( "The load event is executing" );
        document.getElementById("master_btnDelete").style.display = "none";
    }

    // code that will add load event for IE and none-IE browsers
    if (window.addEventListener){window.addEventListener("load",doLoad,false);}
    else 
    if (window.attachEvent) { window.attachEvent("onload",doLoad);}
    else 
    if (window.onLoad) { window.onload = doLoad;}
</script>

Unfortunately Microsoft was not very consistent with IE design, this is why you have to check what event handling method works and should be used. You can use the following two links as a reference if you have more questions on this code:StackoverFlow Question and MSDN Help Page

Now, why your jQuery bases code didn't work? I don't know, could be that the Archer version you code for used a version of jQuery library that doesn't support IE9 well enough. And this brings me to another point.

Usage of the jQuery supplied with Archer

You used jQuery in the original code sample provided. I recommend you not to use any libraries when you write custom objects for Archer.

1. jQuery library you used was provided as a part of the platform. jQuery library can be "custom build" to include the functions you use. Or in this case, to include the jQuery functions Archer developers used. In the next version of Archer this list may get changed. What happens if the functions you used are no longer a part of the library in the latest versions?
2. You don't have a control over jQuery version used. So you can't guarantee the support for certain browsers and you can't force RSA to use latest version. This limits the functionality of your code. And this is exactly what happened here. You used jQuery and it didn't work with IE9. Will it work with IE11? And what happens after you upgrade Archer with latest patch?
3. Keep in mind that the code you write will has to work with another 10k+ lines of JavaScript code loaded with page by Archer already. So keep your custom object as simple as possible and try not to use any external libraries. It is all about support (unless you are there for 1 months and don't plan to support your code).

Summary

1. Don't hide Delete buttons in RSA Archer, but redesign the security.You will regret the decision of hiding Delete button in a long run. One day user will actually delete the record and you will feel the pain.
2. Use KISS principle - use simple JavaScript code, avoid libraries, keep Custom objects short. Avoid custom object whenever possible. Or you will have to test them every time you update the platform.

Good luck, user3728843!

Answer 4

You could also hide elements using simple CSS which is much more likely to work cross-browser

In this case:

#master_DefaultContent_rts_s2487_f6881srvgrid_ctl00 .GridRemoveImage {
  display: none;
}

Answer 5

@StanUteski makes some great points and lays out really good best practices.

Also remember that if a user is using a strange browser like Safari for basic functionality you'll still get weird results.

Also, browsers might have JavaScript turned off accidentally.

Now, you might be saying that doesn't make sense, "...b/c my users know that Archer will only work with '123' specific versions of 'ABC' browsers" - but, that's the point, even if they are the best users in the world, and are completely aware, you can't necessarily control what browser they use, or if they are using a tablet or mobile phone, or if the page loads weird and doesn't completely load a script / libary properly -- even if the page doesn't render, you may still be exposing the button in that case, and creating a possibility of the user clicking and deleting the record.

In all cases, you want to try to stick to an MVC (Model-View-Controller) or MVVM (Model-View-View-Model) programming paradigm for web apps, where the CONTROLLER is on the server side and controls the applications "functional flow and characteristics" - for example - a page with a list of Policies has the following buttons, which lead to their corresponding pages:

• Add
• Edit
• Delete

These buttons and where they lead are then further restricted using User Roles and Permissions (which is actually a DIFFERENT controller's function - basically the Access and Rights Management controller subsytem).

This results in:

• easier to understand application flow from a high-level
• allows the application to be thought out, designed, walked through, from a BUSINESS and process point of view first:

• something that can AND should be done before even touching the development system

  • User Personas representing the user population, that you translate into Roles
  • Use Cases for all Personas/Roles which will allow you to determine for each of the Roles:
    • The subset of data that may be acted upon
    • The actual functionality / actions that could be taken
    • The next steps and decisions from each and every point within within the flow, depending on the restrictions imposed by #1 and #2.

  • Wire-framing for determining:

    • The UI elements required to enable the functionality, actions, and directional flow that has been determined for each step and decision gate within the process.
    • The optimal placement these UI elements to enable:
      1. Quick clear visibility to the information
      2. Most efficient / simple way of performing the actions (least number of clicks, radio buttons instead of dropdowns when only few choices are ever available, e.g. Yes/No, True/False)
      3. An aesthetically pleasing view
      4. A flexible and responsive display
      5. Responsive and informative user hinting and cueing, e.g.:
         • errors
         • required fields
         • inactive buttons
      6. Perhaps even user customizable themes

    • View accessibility:

      1. number
      2. arrangement
      3. visibility
      4. state

      Of the main working "screen" area of the UI, e.g.:

      • panels
      • pages

      And how they are brought into view, using mechanisms like

      • sliders
      • tabs

    a good view leans is efficient and self-documented b/c it is designed to be intuitive in terms of what the user:

    1. the user should see now
    2. the user can see next
    3. how related information can be seen and given the right amount of priority and real-estate
    4. when and how to trade visibility for accessibilty
    5. to do next, to make tabs, , etc.

Finally you can actually get to implementation: which then drives the...

1. data model design which then leads to...

2. controller coding: which in the case of Archer lies in:

   • the Application Builder and how you set up your relations, permissions, and actions

   • any custom CALCULATED fields (which are server-side controller code/constructs) - think of it as a more restricted version of actually coding the ASP pages.

     • In other Web apps you might be doing it in PHP, JSP, Ruby/Rails, etc.
     • But, since Archer is really closer to a 5GL / Domain Specific - Application Development Tool/Environment and Run-time (it's not really a framework as they claim), you are limited to the:
       1. Data presentation (GUI) elements
       2. logic blocks (calculated fields)
       3. and data constructs (tables, levels, etc.) that we find in the Application Builder (except of course for the Custom Objects which are a newer Element)
       4. view design and coding: although in the case of Archer, it's expected that you will use the built-in, encapsulated GUI/view objects (like grids, options dropdowns, menus, etc.), instead of (the rare cases where you might wind up custom coding in JavaScript - client side/views elements).

By always keeping things separated like this you will:

1. Allow for a good separation of labor/ duties
2. allow you to get more done faster / in parallel
3. result in cheaper labor costs, as different skill-sets can be used for:
   • process
   • data modeling
   • controller
   • view
   • etc.
4. Make your applications:
   • more robust
   • more understandable
   • easier to troubleshoot / debug
   • easier to maintain/upgrade
   • quicker to build additional features and functionality for
   • more portable
   • more modular and reusable

---

Design and Development Best Practices

1. have a business person / someone in the CISO's office be responsible for gathering and designing the business process flow:
   • capture what exists not on paper and/or legacy systems:
   • what they'd like it to change into (final state)
2. have a systems analyst then translate the business process flow into a functional application flow that makes sense within Archer's overall:
   • framework
   • modules
   • available data inputs and outputs
   • features
3. have the main Archer Developer implement that application functional design (in this order):
   1. the data model
   2. then the controllers, using (in the follow order - most restrictive [and closest to the data] to least restrictive [farther from the data])
      1. roles and permissions
      2. lookup filters
      3. form actions
      4. calculated fields
      5. custom code (as a very last resort)
   3. Finally the view (which in Archer really is done using the same tool - the Application Builder.
      1. You can decide and place whichever fields, lookup filters, calculated logice, etc. you need first to build your controller/functionality - inputs/outputs.
      2. Then after that work on the view, in terms of:
         • Where elements should go on a page/form
         • How they should look:
           • formatting
           • alignment
           • tooltips
         • Custom GUI / UX bells & whistles

Answer 6

$(document).ready(function(){  
  $('#master_DefaultContent_rts_s2487_f6881srvgrid_ctl00 .GridRemoveImage').hide();
});

OR

$(document).ready(function(){  
  $('#master_DefaultContent_rts_s2487_f6881srvgrid_ctl00 .GridRemoveImage').css("display", "none");
});