Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[state] don't make extra $location.replace() calls #8179

Merged
merged 1 commit into from
Sep 8, 2016

Conversation

spalger
Copy link
Contributor

@spalger spalger commented Sep 7, 2016

Issue:
In order to ensure BWC in the new state-hashing changes, rison encoded query string parameters are automatically converted into hashes and placed back into the URL via $location.search().replace(). This ensures that extra history entries don't get created, but this is still happening when hashing is disabled (which is now the default). This causes every state-caused history change to become a replacement, which mutilates the history stack.

Fix:
Added a #isHashingEnabled() method to the state objects that is called before trying to convert rison encoded query string states and replacing them in the URL.

@LeeDr
Copy link

LeeDr commented Sep 7, 2016

Couple of questions;

  1. is this related to the fix Dashboard with many widgets fails to display in IE11 #4919 ?
  2. I don't understand isHashingEnabled(). Is it a configuration option? Or how does it get set?
  3. Do the functional selenium tests pass locally for you? Or does this change (or Dashboard with many widgets fails to display in IE11 #4919) cause that browser back button test to fail? Or it depends on isHashingEnabled somehow?

@spalger
Copy link
Contributor Author

spalger commented Sep 7, 2016

is this related to the fix #4919 ?

Yeah, the fix for that (#8022) caused the bug

I don't understand isHashingEnabled(). Is it a configuration option? Or how does it get set?

It just reflects the current value of the state:storeInSessionStorage setting, which is what turns on #8022

Do the functional selenium tests pass locally for you?

The tests pass locally, and this is specifically fixing the bug caused by #8022

return null;
}

if (this.isHashingEnabled()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because there are so many conditionals and early-exits in this method, I think it's worth adding a comment describing the state of the app in which this condition is reached:

if (this.isHashingEnabled()) {
  // If Kibana has been loaded for the first time with RISON states URL, and the user has has hashed states
  // enabled, then update the URL to show the hashed states instead of the RISON states.
}

@cjcenizal
Copy link
Contributor

1 comment, then LGTM!

@ppisljar
Copy link
Member

ppisljar commented Sep 8, 2016

i agree with CJ, else LGTM

Issue:
In order to ensure BWC in the new state-hashing changes, rison encoded query string parameters are automatically converted into hashes and placed back into the URL via `$location.search().replace()`. This ensures that extra history entries don't get created, but this is still happening when hashing is disabled (which is now the default). This causes every state-caused history change to become a replacement, which mutilates the history stack.

Fix:
Added a `#isHashingEnabled()` method to the state objects that is called before trying to convert rison encoded query string states and replacing them in the URL.
@spalger spalger force-pushed the fix/stateReplacement branch from 2db123f to 9c52032 Compare September 8, 2016 09:44
@spalger spalger merged commit d2aff6c into elastic:master Sep 8, 2016
@spalger spalger deleted the fix/stateReplacement branch September 9, 2016 23:12
@epixa
Copy link
Contributor

epixa commented Jan 18, 2017

@spalger Since the url state management flag was released in 4.6.4 as well, think we should backport this to 4.6, or is this a non-issue prior to 5.0?

@epixa epixa added the v5.0.0 label Jan 18, 2017
@spalger
Copy link
Contributor Author

spalger commented Jan 19, 2017

Yeah, I'll backport this to 4.6

elastic-jasper added a commit that referenced this pull request Jan 19, 2017
Backports PR #8179

**Commit 1:**
[state] don't make extra $location.replace() calls

Issue:
In order to ensure BWC in the new state-hashing changes, rison encoded query string parameters are automatically converted into hashes and placed back into the URL via `$location.search().replace()`. This ensures that extra history entries don't get created, but this is still happening when hashing is disabled (which is now the default). This causes every state-caused history change to become a replacement, which mutilates the history stack.

Fix:
Added a `#isHashingEnabled()` method to the state objects that is called before trying to convert rison encoded query string states and replacing them in the URL.

* Original sha: 9c52032
* Authored by spalger <email@spalger.com> on 2016-09-07T17:29:12Z
spalger pushed a commit that referenced this pull request Feb 1, 2017
Backports PR #8179

**Commit 1:**
[state] don't make extra $location.replace() calls

Issue:
In order to ensure BWC in the new state-hashing changes, rison encoded query string parameters are automatically converted into hashes and placed back into the URL via `$location.search().replace()`. This ensures that extra history entries don't get created, but this is still happening when hashing is disabled (which is now the default). This causes every state-caused history change to become a replacement, which mutilates the history stack.

Fix:
Added a `#isHashingEnabled()` method to the state objects that is called before trying to convert rison encoded query string states and replacing them in the URL.

* Original sha: 9c52032
* Authored by spalger <email@spalger.com> on 2016-09-07T17:29:12Z
airow pushed a commit to airow/kibana that referenced this pull request Feb 16, 2017
[state] don't make extra $location.replace() calls

Former-commit-id: d2aff6c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants