| Summary: | [pmi] Release information overruns div bounds | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | Wayne Beaton <wayne.beaton> | ||||||
| Component: | Project Management & Portal | Assignee: | Portal Bugzilla Dummy Inbox <portal-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | nathan | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Wayne Beaton
Created attachment 215487 [details] Text overruns horizontal bounds This screenshot is taken from http://projects.eclipse.org/projects/birt/release/4.2.0 Created attachment 215488 [details] Content overruns vertical bounds This screenshot is also from http://projects.eclipse.org/projects/birt/release/4.2.0. In this case, the "description" tab was initially highlighted, then the "plan" tab was activated. If I resize the browser, the div expands to the right size and the footer moves to the expected location. The vertical boundary issue is a bug in the Equal Heights CSS library this is enabled as part of the theme by default. I've disabled this CSS and it seems to have resolved the issue. For the horizontal boundary inside the Target Environments field the BIRT project is defining the table to have a width of 825px. This causes the entire horizontal tabs pane to use this width. Removing this style tag resolves the width issue. We should discuss how we can remove the use of style tags from HTML items in the input filter for fields. (In reply to comment #3) > For the horizontal boundary inside the Target Environments field the BIRT > project is defining the table to have a width of 825px. This causes the entire > horizontal tabs pane to use this width. Removing this style tag resolves the > width issue. > > We should discuss how we can remove the use of style tags from HTML items in > the input filter for fields. Is this something that we can/should just handle as part of the export/import process? I've created a new bug: 379290 to track this new issue of handling HTML data. I think it's seperate enough to create a new bug. |