Fix breadcrumbs width calculation #8588
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Setting the width of the parent element of the breadcrumbs and then explicitly calling "_resize" is enough to test the resizing behaviour. This makes possible to remove the "setMaxWidth" method and its related code, which was used only for testing purposes. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The "usedWidth" attribute was not used elsewhere outside the "_resize"
method, so it was replaced with a local variable. Moreover, it was also
renamed to a more suitable name ("availableWidth").
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
There is no need to call "setDirectory" again in resize tests; it is enough to simply resize them (and isolates them better to just test the resizing behaviour). Signed-off-by: Daniel Calviño Sánchez <[email protected]>
There are some differences in width handling between the browsers used to run the tests, most likely due to their support (or lack of) of certain CSS features: PhantomJS requires "width" to be set (probably because it does not handle flex displays and treats it like a block, so "min-width" does not matter in this case), while Firefox requires "min-width" to be set (otherwise the children of "#controls" could be compressed due to its use of flex display and the elements would end with a different width than the one needed for the tests). Due to all that the width of the breadcrumb siblings must be specified in the tests using both "width" and "min-width". Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Other apps could add elements to the controls outside the creatable actions div (for example, the button to switch to the gallery), so the widths of all the visible siblings of the breadcrumbs have to be taken into account in the size calculations. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
When the parent element of the breadcrumbs was resized to a larger width and the siblings of the breadcrumbs expanded to fill all the available width some crumbs could be hidden even if there was enough room for them. The reason was that the width of the siblings being used to calculate the available width for the breadcrumbs was the expanded width of the siblings. Now as many crumbs as possible (that is, fitting in the parent, no matter the siblings) are first shown so the expanding siblings are compressed before calculating the available width. Due to the lack of support for flexboxes in PhantomJS the related unit test is skipped; it has to be run in other browser, like Firefox. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
This ensures that the resize tests do not depend on the values set in the CSS files. Note that this change causes a test to fail with Firefox, but not with PhantomJS. This is due to a difference in the starting width used by Firefox and by PhantomJS, and it will be fixed in a following commit. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
When calculating the total width of the crumbs only its padding was taken into account; now the margin is too. In a similar way, before showing a crumb only its width was taken into account; now its padding and margin are taken into account too. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The "Shows only items not in the breadcrumb" test was failing when run on Firefox, but not on PhantomJS. This was caused by the differences in the starting width between both browsers and an incorrect setup of the test (the width set for the crumbs was overriden when the breadcrumbs were rendered again, and the breadcrumb was resized to 300 from an indeterminate initial width). Now the crumbs are rendered and then its width, padding and margin are set to a known value. Then it is resized to 1000px, which ensures that there will be enough room for all the crumbs and thus the menu will be hidden, and finally it is resized to 300, which causes the middle crumb to be hidden and the menu to be shown. Note, however, that the test now always fails, no matter if it is run on PhantomJS or on Firefox; if the menu crumb is hidden when "_updateMenu" is called it will show it, but it will also wrongly try to add the menu itself to the menu. As the "crumb-id" of the menu crumb is "-1" this causes the last regular crumb to be added to the menu. This will be fixed with other related issues in the next commit. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The crumb for the menu was shown like any other crumb when calling "_showCrumb", but it was also shown when other crumbs were hidden without taking into account the available width. This caused several related problems, like the breadcrumbs taking too much space when the menu was sometimes shown after the rest of the crumbs were adjusted to the available width, or the menu being shown instead of the last crumb even if there was room for it when the available width was increased. Now the menu is always hidden before starting the resizing of the crumbs to ensure that whether it was previously shown or not does not affect the result. In a similar way, the menu will no longer be shown by "_showCrumb", as it is not a regular crumb that has to be shown simply if there is enough room. The menu is now shown as soon as any other crumb is hidden; this ensures that the menu width will be taken into account in further width checks. As when _updateMenu" is called it no longer needs to take care of showing the menu this fixes the issue revealed when fixing the test setup in the previous commit. Finally, this implicitly fixes the failure in the breadcrumbs tests when run on Firefox, as it was caused by the menu interfering in the calculations of the other crumbs when increasing the width. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
After the changes in the previous commit "_showCrumb" no longer shows the menu, only the same crumb that was hidden by the last call to "_hideCrumb". Therefore, if the crumb was hidden because it did not fit there is no need to try to show it again, as it will still not fit. Moreover, the calculated width for a hidden element is not always accurate; in some cases the calculated width is lower than the actual width (it happens, for example, when using a background image like the "Share" icon), which causea the crumb to be shown even if there is not enough room, which in the end causes the siblings to overflow the contents. No unit tests for this one, though; you will have to trust me on this, sorry ;-) Signed-off-by: Daniel Calviño Sánchez <[email protected]>
"getTotalWidth" is not more accurate; it is simply not clamped. Moreover, "width/outerWidth" could be used in tests too, and also even if "getTotalWidth" could be used in tests while others not that would not be something to be stated in the API documentation, but in a comment. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Menu and home are not always visible; home is always visible, but menu is shown only when needed. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
skjnldsv
approved these changes
Mar 1, 2018
rullzer
approved these changes
Mar 1, 2018
Thanks! :-D
That is a related but different issue (and it happened before these changes too ;-) ); the breadcrumbs compress the siblings to find out how much is the minimum width that they need, but as the message is a I do not know how to fix that, though, as the needed width for the text depends on the language, so it is not possible to set a hardcoded |
skjnldsv
added
4. to release
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request fixes several corner cases with the width calculation of the breadcrumbs:
For further details and a neverending read please refer to the commit messages :-P
How to test:
When the breadcrumbs are resized the gallery button should never overflow the file list width. If it does then please give me the details (browser width, directory names, if you increased or decreased the width, etc) to be able to replicate and study it (although I hope that you do not find any issue, because if there is still something that I have not fixed yet I will curl up in a corner and cry :-P ).
*Note, however, that there are some points in which the progress bar width switches from 200px to 50px, and it also depends on whether the navigation bar is shown or not, so the behaviour while resizing sometimes is a bit surprising.
These fixes should be backported to stable13, as they are required by nextcloud/gallery#401, which will have to be backported too when #8589 is backported to stable13.