Details
-
Suggestion
-
Resolution: Won't Do
-
None
-
None
-
1
-
Description
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
We have recently discovered that the fixed edit bar (i.e. that when a user is on a page and has scrolled down a bit, the user only has to scroll up to trigger the edit-bar to be shown in the page) only works for pages that do not incorporate the style-tag. If the style-tag is present on a page, the edit-bar remains at the top of the page. This means that any page having a macro that has a style-tag will not have the popup-edit bar, instead it will have the old behavior, leading to what may be considered an inconsequent behavior across the Confluence-instance.
https://maven.atlassian.com/content/repositories/atlassian-public/com/atlassian/confluence/plugins/confluence-fixed-headers/1.2.8/ in the file: confluence-fixed-header.js:
// CONFDEV-36692 do not active if custom CSS is detected if ($('#main-content').find('style').length > 0) { 3 return; 4 }
Steps to replicate
1. Enabling HTML-macro in Confluence (under Manage add-ons > System-installed > HTML).
2. Adding an html-macro to a page that has a styles tag.
Tested Chrome, Safari and Firefox with Confluence 5.9 and Confluence 5.10, since the fixed edit bar was introduced.
Having it as a feature that can be turned on or off on a global level, the implementing instance could decide for themselves if this is a feature that should be there or not. From our side we have also noticed that there are add-ons that are not compatible due to this issue, and this too would be a scenario where an opt-in/opt-out would be app
Attachments
Issue Links
- is related to
-
CONFSERVER-43099 Edit bar does not re-trigger if style-tage applied on the page, the edit bar remains at the top of page instead
- Closed
- relates to
-
CONFCLOUD-43182 Make Edit bar possible to opt-in and out of fixed header/edit ba
- Gathering Interest