Closed Bug 307076 Opened 15 years ago Closed 15 years ago
Menus on WYSIWYG editors open on wrong place
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050904 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050904 Firefox/1.0+ Posting on topics from http://www.dslteam.de/forum/ using the WYSIWYG editor and trying to edit the font type makes the menu open on a wrong place (only visible if I scroll the page) Reproducible: Always Steps to Reproduce: 1. Go to http://www.dslteam.de/forum/ . You will need an account to be able to post. You can use Bugmenot for it: http://bugmenot.com/view.php?url=http%3A%2F%2Fdslteam.de 2. Go to any forum and try to open a new topic clicking on "Neues Thema" button. 3. On the WYSIWYG Editor try to change font type or font size by clicking on the menu. 4. Apparently it doesn't open. 5. Scroll the page and you will see the menu under the whole editor. Actual Results: The menu opens on the wrong place. Expected Results: Menu opens directly under the scrollbox.
I think it is because the containing table cell has position:relative; Position:relative doesn't work in Mozilla1.7, but seems to work now in current trunk builds. When removing that style rule, the menu gets on the right place. So I think this is a tech evangelism issue.
Hmm, position:relative is still not working on table cells, so that can't be it (strange that it makes the difference here, then). Anyway, I still think this is probably tech evangelism, but a minimal testcase is needed for that.
Assignee: general → nobody
QA Contact: general → layout
As additional information, it works fine with Firefox 1.0.4.
I was able to point a regression date. It works fine with 2005-03-21 build but stopped to work on 2005-03-22. On 2005-03-22 it's also impossible to put any text on textbox. This issue was solved on 2005-04-06, but it started the issue on scrollbox menu.
Ok, this is a minimal testcase. The behavior for the red bordered popup changed, but it changed in fact for the better. The green bordered popup still shows the old, wrong behavior. So the WYSIWYG editor relies on the fact that td style="position:relative" doesn't work. But I think this is not good behavior, both popups should at least act the same.
Attachment #194900 - Attachment is obsolete: true
Thanks Pardal! When looking at the regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-03-21+05%3A00%3A00&maxdate=2005-03-22+10%3A00%3A00&cvsroot=%2Fcvsroot The only bug that could have caused this seems bug 282754.
Component: Layout → Layout: R & A Pos
QA Contact: layout → layout.r-and-a-pos
Robert, you might want to take a look at this bug. Maybe it is something that needs to be fixed for the 1.8 branch.
Assignee: nobody → roc
dbaron, can you look into this regression?
I'm pretty sure this is nsCSSFrameConstructor being inconsistent: it's probably not pushing an absolute containing block for rel-pos table cells, but it is probably finding an absolute containing block when we dynamically create the frame.
Be more consistent ... no table-related frames push absolute containing blocks so we shouldn't treat them as abs containing blocks.
Comment on attachment 198046 [details] [diff] [review] fix Looks ok, but we should make sure we fix this as we fix other issues (eg if we make table caption construction use ConstructBlock).
checked in to trunk.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment on attachment 198046 [details] [diff] [review] fix need approval for this blocker bug
Attachment #198046 - Flags: approval1.8b5?
Comment on attachment 198046 [details] [diff] [review] fix approving for the branch. Thanks roc.
Attachment #198046 - Flags: approval1.8b5? → approval1.8b5+
checked in on branch.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050930 Firefox/1.6a1 ID:2005093016 Looks good to me.
Status: RESOLVED → VERIFIED
Pushed a testcase: http://hg.mozilla.org/mozilla-central/rev/df1c424265ab
You need to log in before you can comment on or make changes to this bug.