Feedback for DHTML-loading of Issue screens

JIRA Documentation

Index

Please add any feedback you have about the 'DHTML-loading of Issue screens' in JIRA 3.8 as a comment to this page.

We would be very interested to know whether you think the feature is useful and hear about any problems that you find.

Currently we know about the following issues:

  1. JRA-12348
  2. JRA-12349

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Apr 10, 2007

    Werner Huber says:

    Insert-Focus is not on first field in screen. When I "Log Work done" to an Issu...

    Insert-Focus is not on first field in screen.

    When I "Log Work done" to an Issue:

    without DHTML-loading the Focus is in the Field " Time Spent:"

    with DHTML-loading turned on, the Focus is "nowhere" (most outer frame)

    --> so there is (just) one more klick for each entry.  but: we have to use a external Time-Tracking tool, and so my job is, to copy the times into JIRA. ~150 to 200 lines each monday .....

    1. Apr 10, 2007

      Anton Mazkovoi says:

      Thanks for your report! I have raised: http://jira.atlassian.com/browse/JRA-125...

      Thanks for your report!

      I have raised:
      http://jira.atlassian.com/browse/JRA-12529

      Please watch the issue to get updates on this bug.

      Thanks again!

      Anton

  2. Jun 05, 2007

    Mark Chaimungkalanont says:

    I've been using JIRA with the feature turned on for a bit now, and don't really ...

    I've been using JIRA with the feature turned on for a bit now, and don't really like it.

    The main gripe I have is that it overrides my browser actions I've known for years. Things like expecting the "Back" action to go to the previous page no longer works. This was initially puzzling, and now just little frustrating. Two scenarios:

    1. If you've opened an issue on the View Issue screen and then click "Edit", clicking back does nothing.
    2. In other cases, clicking back goes back one screen too far, which makes it especially confusing when you're editing a series of issues through the Next & Previous links on the top right.

    Other smaller peeves include:

    1. The edit screen always have the default font size. In FireFox if you increse the size of a page and the click Edit, the iframe is still the default size.
    2. Shortcut keys don't work after cancelling. If you do manage to retrain yourself to use the cancel button to go back rather than the back button, no other access keys seem to work until you change the focus back to the current page.

    Moreover, I don't see any real performance benefits out of it. The only thing that doesn't get reloaded are the headers and side bar. Which amounts to around 11k (with whitespace, no gzip) whereas an edit page for Bamboo 38k (no headers etc). Which isn't a lot in the scheme of things, especially if people are using (FF in SSL).

    AFAIK, the only thing holding back a full Ajax solution to this is that custom fields may have inline Javascript events handlers? If this is so, maybe a option is to deprecate the use of inline event handlers now, and implement Ajax issue operations for 4.0 or some such.

  3. Jul 31, 2007

    Joakim Johansson says:

    I tried enabling this feature with 3.9.3, it seems it doesn't work for Apple's S...

    I tried enabling this feature with 3.9.3, it seems it doesn't work for Apple's Safari 3.0.2 web browser at all (nothing happens at all when clicking on Edit for an issue).