-
Bug
-
Resolution: Fixed
-
Minor
-
-
Blue Ocean 1.0-rc4, Blue Ocean - 1.1-beta-1
Closing the modal results screen always closes it, but the URI sometimes has an incorrect path. The side effect of this is if you click on anywhere else, you get a full page reload.
To reproduce:
- Open a pipeline finished run - note the URI (call that URI A)
- Click on any stage - note the URI changes with the stage id (call that URI B)
- Close the modal
- Note that screen shows activity (where you originally came from) BUT the URI == URI A
- Click on branches/activity and note you get a page reload
It should show /activity or wherever it came from. It shouldn't just go back on item in the history.
In Scope:
- Fix
- Unit or ATH test to ensure that the close actually restores the correct URI
Perhaps this is best done with a change - don't use path to set stage ids, use a query parameter, that way "back" will go back to the correct place. Or close needs to push the history to where it remembers it originally came from... I dunno. Maybe the 2nd amendment people can do something about that, I don't know. FAKE NEWS.
[JENKINS-43217] Closing pipeline results "modal" after clicking on a stage sets the url incorrectly to the previous URL, not activity
| Epic Link | New: JENKINS-35750 [ 171713 ] |
cliffmeyers ah nice one - want to pick this one up at some point? If you think this warrants an ATH - go for it. I think it is subtle enough that people either don't see it, or what they do after closing it, means that it doesn't affect them anyway (other than a blink-reload), or we would have heard more. As it is subtle though, it may generate some confusion but not enough for people to open a ticket. I only saw it as Thor and I were reviewing the latest karaoke changes.
I will bump it up.
| Description |
Original:
Closing the modal results screen always closes it, but the URI sometimes has an incorrect path. The side effect of this is if you click on anywhere else, you get a full page reload. To reproduce: * Open a pipeline finished run - note the URI (call that URI A) * Click on any stage - note the URI changes with the stage id (call that URI B) * Close the modal * Note that screen shows activity (where you originally came from) BUT the URI == URI A * Click on branches/activity and note you get a page reload It should show /activity or wherever it came from. It shouldn't just go back on item in the history. Perhaps this is best done with a change - don't use path to set stage ids, use a query parameter, that way "back" will go back to the correct place. Or close needs to push the history to where it remembers it originally came from... I dunno. Maybe the 2nd amendment people can do something about that, I don't know. FAKE NEWS. |
New:
Closing the modal results screen always closes it, but the URI sometimes has an incorrect path. The side effect of this is if you click on anywhere else, you get a full page reload. To reproduce: * Open a pipeline finished run - note the URI (call that URI A) * Click on any stage - note the URI changes with the stage id (call that URI B) * Close the modal * Note that screen shows activity (where you originally came from) BUT the URI == URI A * Click on branches/activity and note you get a page reload It should show /activity or wherever it came from. It shouldn't just go back on item in the history. In Scope: * Fix * Unit or ATH test to ensure that the close actually restores the correct URI Perhaps this is best done with a change - don't use path to set stage ids, use a query parameter, that way "back" will go back to the correct place. Or close needs to push the history to where it remembers it originally came from... I dunno. Maybe the 2nd amendment people can do something about that, I don't know. FAKE NEWS. |
Code changed in jenkins
User: Cliff Meyers
Path:
src/main/js/custom_commands/index.js
src/main/js/custom_commands/waitForLocationChange.js
src/main/js/custom_commands/waitForLocationContains.js
src/main/js/page_objects/blueocean/bluePipelineRunDetail.js
src/test/js/edgeCases/runDetailsDeepLink.js
src/test/js/runDetailsModal/runDetailsFallbackNavigation.js
src/test/resources/test_scripts/hello-world.groovy
http://jenkins-ci.org/commit/blueocean-acceptance-test/49e8845912961e76e3cb7518c46a348419e3dfda
Log:
JENKINS-43217 rewrite waitForLocationChange -> waitForLocationContains so it doesn't require the URL to actually change, as it could be brittle due to timing issues; rework "closeModal" page object command to just wait for the RunDetails-content element to go away; refactor the "runDetailsDeepLink" test to "runDetailsFallbackNavigation" and adjust to new API
| Assignee | New: Cliff Meyers [ cliffmeyers ] |
| Sprint | Original: Blue Ocean 1.1 [ 271 ] | New: Blue Ocean 1.0-rc4 [ 281 ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Code changed in jenkins
User: Cliff Meyers
Path:
src/main/js/custom_commands/index.js
src/main/js/custom_commands/waitForLocationChange.js
src/main/js/custom_commands/waitForLocationContains.js
src/main/js/page_objects/blueocean/bluePipelineRunDetail.js
src/test/js/edgeCases/runDetailsDeepLink.js
src/test/js/runDetailsModal/runDetailsFallbackNavigation.js
src/test/resources/test_scripts/hello-world.groovy
http://jenkins-ci.org/commit/blueocean-acceptance-test/2c3845dee290443631d6626a13d3ca7b1a853cd7
Log:
JENKINS-43217 rewrite waitForLocationChange -> waitForLocationContains so it doesn't require the URL to actually change, as it could be brittle due to timing issues; rework "closeModal" page object command to just wait for the RunDetails-content element to go away; refactor the "runDetailsDeepLink" test to "runDetailsFallbackNavigation" and adjust to new API (#132)
This also occurs if the user clicks on any tabs after opening the modal and then closes it.
Be advised that in addition to the "full page reload after click" problem, the DOM shown in the browser is a snapshot that is "disconnected" from React and MobX, and therefore won't update in real time.
I might suggest upgrading the priority of this bug.