Project

General

Profile

Actions

Bug #2467

closed

http://www.webtoolkit.eu/widgets/navigation/navigation-bar responsive bug

Added by Anonymous over 10 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
11/25/2013
Due date:
% Done:

0%

Estimated time:

Description

In Chrome and in Firefox, when I make a browser thin (<700px) and navbar shows data, when I click Help in Menu text of Contents, Index, About is over "Enter search item" edit, it should be hidden (not visible). Link:http://www.webtoolkit.eu/widgets/navigation/navigation-bar


Files

fix-wt.png (74.8 KB) fix-wt.png Screenshot After Possible Solution Josh Lampco, 11/25/2013 11:42 PM
abs-pos-wt.png (63.3 KB) abs-pos-wt.png Screenshot of Problem Josh Lampco, 11/25/2013 11:42 PM

Updated by Josh Lampco over 10 years ago

I am experiencing this issue also in Google Chrome Version 31.0.1650.57. However, I have come across it while implementing the navigation menu widget within my own development project. I am using Bootstrap V2.2.2 and Wt V 3.3.0.

It seems as though the JavaScript associated with Wt, is adding absolute positioning to the unordered list associated with the class "dropdown-menu". When I change the positioning to static, as it is in the bootstrap-responsive.css v2.2.2, and also delete the following style

.nav-collapse .dropdown-menu {
    display: block !important;
}

which is found in wt.css, I see that the layout is corrected.

I have attached screenshots of the bug as seen here. In the developer tools console at the bottom of the attached images, I have shown what I changed.

Actions #2

Updated by Josh Lampco over 10 years ago

After further testing, simply adding static positioning will not fix the problem. A media query will need to be used as the menu needs static positioning only when the browser window is less than 979px.

@media (max-width: 979px) {
    .nav-collapse .dropdown-menu {
        position: static !important;
    }
}

Keep in mind that at this point my solution is very "hacky". Hopefully, someone can come up with a better solution that does not involve media queries and overwriting the JavaScript.

Actions #3

Updated by Koen Deforche over 9 years ago

  • Status changed from New to InProgress
  • Assignee set to Koen Deforche
  • Target version set to 3.3.4
Actions #4

Updated by Koen Deforche over 9 years ago

  • Status changed from InProgress to Resolved

This problem appears to have been solved already.

Actions #5

Updated by Koen Deforche about 9 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF