Defect #1965

Redmine is not Tab Safe

Added by Ewan Makepeace about 9 years ago. Updated 5 months ago.

Status:ClosedStart date:2008-09-29
Priority:HighDue date:
Assignee:Jean-Philippe Lang% Done:

100%

Category:UI
Target version:1.2.0
Resolution:Fixed Affected version:

Description

I think this relates strongly to the push towards making Redmine more RESTful but had thought that just benefited a programmatic API. However today I hit this nasty issue. To reproduce:

  1. Open an issue view eg: http://www.redmine.org/projects/redmine/issues?query_id=1
  2. Hold down Ctrl/Cmd to open another view in a new tab in your browser: http://www.redmine.org/projects/redmine/issues?query_id=2
  3. Return to the first tab and click the link for a CSV file: http://www.redmine.org/projects/redmine/issues?format=csv

If you look at the URL you can already see the problem - there is nothing there to tell Redmine which view to generate the CSV for, and so it uses its own context to (wrongly) generate CSV for the last view displayed, not the view requested. This is particuarly insidious because depending what you do with the CSV you might not even notice the switch (I have been generating team bonus numbers with mine and two developers complained that their numbers suddenly went down - perhaps this is why).

In general web applications need to not only be thread safe but tab safe these days - even without tabs a user can click the back button to go to a previous display before following a link, so the assumptions made by this link are never safe.

[Side issue: When working on multiple tabs I often get the "Successful update" message on tabs other than the one that I used to save a change. Is that a limitation of Rails or Redmine?]


Related issues

Related to Redmine - Patch #7594: Proper pagination Closed 2011-02-09
Related to Redmine - Defect #5138: Don't use Ajax for pagination Closed 2010-03-20
Related to Redmine - Defect #3494: Browser "Back" to issue list displays wrong filter Closed 2009-06-13
Related to Redmine - Defect #657: Back button - loses current page after viewing an issue -... Closed 2008-02-13
Related to Redmine - Defect #6956: Back to search results go to first record Closed 2010-11-22

Associated revisions

Revision 5276
Added by Jean-Philippe Lang over 6 years ago

Converted issue filters to non-AJAX GET requests (#1965).

Revision 5297
Added by Jean-Philippe Lang over 6 years ago

Changed timelogs filters to use non-AJAX requests (#1965).

History

#1 Updated by Jim Jones about 9 years ago

+1

#2 Updated by Ewan Makepeace almost 9 years ago

This is the one that bit me but I often see cases where Redmine gives the 'wrong' results because I am moving between active tabs. This is such a fundamental breach of basic web application principles that I am quite dissapointed - surely we need to get Web 1.0 right before worrying about Web 2.0 bling?

#3 Updated by Jean-Baptiste Barth over 7 years ago

For the issue you're reporting, I totally agree it's not OK. But it may be a more general issue about "filters kept in session". I can provide a patch for these specific links, but now it depends on where we want to place the cursor... You talk about other places where you saw this problem, can you list them here ?

Anyway, about what you present as a "Side issue", it's a rails problem (if any) : flash messages are kept in session and deleted when the next page is displayed. If you open many tabs some flash messages are not displayed where you expect but I don't think it's a big deal...

#4 Updated by Brian Lindahl almost 7 years ago

The same root cause (lack of context in the URL) also makes using the back button near impossible. Do an issue query, then scan forward several pages by hitting the 'Next' link. Then click on a link to an issue. Then hit the back button. The user will return to the first page of the issue query. The user now has to renavigate to page #x - hopefully they remember what page they were on!

Another example of extremely annoying non-Tab-safe behavior is when you open multiple queries in seperate tabs. Go back to the first tab (first opened query) and hit the next button. You will now see page 2 of the last opened query (not the first opened query).

#5 Updated by Brian Lindahl almost 7 years ago

Oh, another problem with the back button is that when you click a link to an issue, and then hit the back button, your query (if non-saved) will be cleared out and you'll have to re-create the query again.

#6 Updated by Brian Lindahl almost 7 years ago

related to #3494

#8 Updated by Brian Lindahl over 6 years ago

This also?:
http://code.google.com/p/reallysimplehistory/

I like modifying the URL with a '#' mark to designate the page number a little better, mainly due to it's adherence to KISS. However, it still doesn't solve all problems.

#9 Updated by Brian Lindahl over 6 years ago

Related to #5138.

#10 Updated by Brian Lindahl over 6 years ago

related to #657

#11 Updated by Brian Lindahl over 6 years ago

In #7594, I've created a patch to temporarily solve this problem until a real solution exists. It disables Ajax updates and uses direct linking for pagination.

#12 Updated by Dustin Lambert over 6 years ago

While the patch helps, I think the bigger issue is the fact that filters are kept in the session.

#13 Updated by Brian Lindahl over 6 years ago

Very true.

#14 Updated by Dustin Lambert over 6 years ago

Solving this would make it very easy to collaborate with others as well.

For instance, if I want to provide someone with a link to a list of issues, I currently have to save the query as public and send it to them.

I should be able to just send them the url.

#15 Updated by Ewan Makepeace over 6 years ago

+1

I thought that was where we were heading with a RESTful API?

#16 Updated by Etienne Massip over 6 years ago

  • Category set to UI

#17 Updated by Jean-Philippe Lang over 6 years ago

  • Assignee set to Jean-Philippe Lang
  • Target version set to 1.2.0

#18 Updated by Jean-Philippe Lang over 6 years ago

I'm going to change the issue filter requests to regular GET requests (non-AJAX) so that the URL actually reflects the filters being applied. All these filters parameters need to be added to pagination and export links too, so that 2 tabs with different filters can be used at the same time. This will solve the problem initially described here.

Pagination links should be turned into regular GET requests as well, as there's a lot of issues reported about the behaviour of the browser back button (and I don't really want to add javascripts hacks to fix the browser history).

I think that storing the last query in session is still needed so we get it back when clicking the 'Issues' tab after navigating away from the issues.

#19 Updated by Etienne Massip over 6 years ago

Agree with all points, will be good to keep filters when using f5 to refresh the query page.

Hope this won't have too much impact on performance ; the list is updated immediatly after using the Apply button as for now.

#20 Updated by Jean-Philippe Lang over 6 years ago

The impact is not so big, same difference as today between clicking the 'Apply' link and the 'Issue' tab.

#21 Updated by Etienne Massip over 6 years ago

Yes. I liked the "Loading..." message too.

Doesn't a proper technique to keep using Ajax and having an up-to-date url already exist ?

#22 Updated by Etienne Massip over 6 years ago

Just ran some UX "tests", you're definitely right, this should be changed to GET request.

#23 Updated by Jean-Philippe Lang over 6 years ago

  • % Done changed from 0 to 50

Work done in r5276 to r5280. Same change needs to be done for time entry filters.
Pagination links are still using AJAX for now.

#24 Updated by Jean-Philippe Lang over 6 years ago

  • Resolution set to Fixed

Pagination links changed to non-AJAX in r5302.

#25 Updated by Stanislav German-Evtushenko over 6 years ago

Should it be closed?

#26 Updated by Ewan Makepeace over 6 years ago

Question regarding this comment in http://www.redmine.org/issues/1965#note-18 by JPL:

I think that storing the last query in session is still needed so we get it back when clicking the 'Issues' tab after navigating away from the issues.

Personally I dont find that a feature. It seems that when I click the Issues tab what I get is different each time, depending on my history, and rarely seems to match what I want. If I am clicking on the tab rather than one of my saved queries within the interface, or one of my many bookmarks, then my intention will usually be "All Issues" so that I can construct a new custom query that I have not saved previously.

I am not being snarky here - I am sure that the current behaviour was implemented based on user requests and is probably used and loved by many, just saying, for me it has no value and perhaps this is the right moment to ask the question of others - is this behaviour worth preserving?

PS This issue got no attention for so long I had all but given up hope. I am really glad and grateful to see all the effort that is going into these changes - the refactorings are quite tedious and tricky and do not get a lot of recognition due to the concealed nature of the problem. Many thanks!

#27 Updated by Ewan Makepeace over 6 years ago

Addendum - perhaps storing the last query in session was intended as a substitute for a working 'Back' button and if we fix Back behaviour it wont be needed any more?

#28 Updated by Jean-Philippe Lang over 6 years ago

I agree. But as you said, some people may be used to this behaviour and I don't want to simply remove it.
Should we consider to add a user preference, like "Remember the issue filters during my session" or something?

#29 Updated by Etienne Massip over 6 years ago

I'm used to this behavior and this may be particularly useful when switching from Issues tab to Gantt tab and vice versa.
Maybe is there some specific query settings which should be stored in session and some others no (just a thought).

#30 Updated by Michael Aye over 6 years ago

A user preference is always the nicest way to treat interface changes/adaptations. That doesn't leave high-hysteresis users in the cold water, while it's possible to implement changes that seem to make more sense for others. Go for it!

#31 Updated by Manuel Becerra over 6 years ago

  • % Done changed from 50 to 100

#32 Updated by Manuel Becerra over 6 years ago

  • % Done changed from 100 to 50

#33 Updated by Manuel Becerra over 6 years ago

  • % Done changed from 50 to 80

#34 Updated by Etienne Massip over 6 years ago

  • % Done changed from 80 to 50

Is it done for revisions list too ? If not, I think that it would be usefull ?

#35 Updated by Etienne Massip over 6 years ago

Etienne Massip wrote:

Is it done for revisions list too ? If not, I think that it would be usefull ?

Looks like it was already tab safe, although I thought I've seen some place it was not ?!

Sorry for noise...

#36 Updated by Terence Mill over 6 years ago

So that issue can get closed, until other reports?

#37 Updated by Jean-Philippe Lang over 6 years ago

  • Status changed from New to Closed
  • % Done changed from 50 to 100

Yes. The user preference for not storing the last query in session needs a bit more feedback/work and will be done later.

#38 Updated by Pierre-Luc Samuel over 6 years ago

I think that if the behavior has to change, it ought to be something that would address #7360 (Issue Custom Query: Default Query). Each project should have a default Issue query, and would be nice if it were overridable per-user (one user prefers the "Only my issues" query while the project manager prefers the "Priority 1 bugs" query).

Also available in: Atom PDF