49.61 KB, image/png
34.47 KB, image/png
861 bytes, patch
|Details | Diff | Splinter Review|
36.30 KB, text/html
Here is a typical screenshot of the UI I get with Fx 184.108.40.206: http://landfill.bugzilla.org/qa30pg/attachment.cgi?id=379 This UI is the official one we are going to release in Bugzilla 3.0. mconnor told me yesterday this was probably due to a reflow bug (-> CC'ing dbaron and roc) on the Mozilla 1.8 branch and that it was probably fixed on trunk. He also told me it was very unlikely to see it fixed on the 1.8 branch. The problem is that Fx2 is the current stable browser, not Fx3a2, and Bugzilla belongs to Mozilla, and so releasing a product which doesn't display correctly with another Mozilla product looks really non-professional. dbaron, roc: do you know any workaround to fix the UI, e.g. using CSS? Or is there a "trivial" fix for Fx2? mkanat, justdave, myk: I don't think we can release Bugzilla 3.0 with such a bug, unless you want to suggest Bugzilla users to move to IE...
The UI I was talking about
Where's the HTML+CSS that generated those screenshots? It's hard to suggest a workaround or fix based on a screenshot alone.
(In reply to comment #2) > Where's the HTML+CSS that generated those screenshots? It's hard to suggest a > workaround or fix based on a screenshot alone. > Any Bugzilla 3.0 installation will work, e.g. http://landfill.bugzilla.org/qa30/show_bug.cgi?id=4316 which is our QA installation for 3.0.
I don't see anything resembling the screenshots when loading that page in Linux Firefox 220.127.116.11. How about some steps to reproduce, since they seem to be more complicated than load the page and resize the window to different widths?
Sorry, I forgot to specify this here (I only did when writing to the mailing list): First, choose the user pref to redisplay the bug you just edited. Then edit a bug. After you click "Commit", the updated page may be broken, as in the 2 screenshots above. This behavior is not systematic. In my case, it happens in 50% of cases. One example to reproduce the bug is to edit flags and some other fields at the same time. ajschult said on IRC it may be related to the network connection speed, so it may be the reason why some users cannot reproduce the bug.
FWIW, I was not able to reproduce this with those instruction on a "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168pre) Gecko/20070208 BonEcho/22.214.171.124pre ID:2007020804" nightly build.
can specified widths fix this? (this bug cannot be reproduced here)
Attachment #255516 - Flags: review?
Comment on attachment 255516 [details] [diff] [review] patch for tip I thought about that too, but applying your patch doesn't fix it, unfortunately.
Attachment #255516 - Flags: review? → review-
GavinS can reproduce it on Mac OS X, and I can reproduce it on Linux/KDE, but wicked cannot with Windows 2000, nor can Tomcat with Windows XP: <Tomcat> wfm on Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:126.96.36.199) Gecko/2007021518 Firefox/188.8.131.52 Mnenhy/0.7.5.0 Maybe are Windows users not affected? Note that I also tried with Fx 184.108.40.206 (rc4) and SeaMonkey 1.1, and I can reproduce the problem in all cases.
WFM with Opera/9.10 (X11; Linux i686; U; en) WFM with Konqueror 3.5.4 WFM with IE6 on Linux (using IEs4Linux)
I can reproduce on Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:220.127.116.11) Gecko/20061204 Firefox/18.104.22.168 Mine looks like Gavin's screenshot.
wfm on XP x64 and on Linux Fedora FC6 , looks fine for me and was not reproducible
mkanat: based on the feedback we got here and on IRC, only a few users are able to reproduce the bug, and this issue is not systematic, even for me (i.e. I have no testcase where I can reproduce the bug in 100% of cases). So we should go on with 3.0 RC1, but relnote this issue anyway. Then we will see how users are affected, based on feedback we will get. Sounds good?
It probably wouldn't be too hard to make a testcase for the problem based on http://weblogs.mozillazine.org/hyatt/archives/2003_08.html#003963 . Then it might be easier to suggest a workaround. That said, this seems like overuse of floats to me.
(In reply to comment #14) > So we should go on with 3.0 RC1, but relnote this issue anyway. Then we will > see how users are affected, based on feedback we will get. Sounds good? Yep! Sounds good. :-)
I confirm this issue on Bugzilla 2.23.4 with Firefox 22.214.171.124 (Windows).
Bad! I have been able to get such a bad overlap just right now again, so that's not so infrequent. Maybe it's only a coincidence, but the overlap is worse for users without editbugs privs (which would mean 99% of users on an installation like b.m.o).
From our own use of bugzilla: it seems that after a form post the page renders like those screenshots almost every time. It has been happening for at least the past couple months (at least since Bug 357534). We get two different overlaps; sometimes it is as bad as the first screenshot and other times it is just like the second. Both times it fixes itself when you make a selection in a dropdown box or some other reflow causing activity (the slashdot reflow greasemonkey script fixes it too). We figured it was a bug in Firefox (hence I didn't report it here). I would vote that this does not block the release. It is an annoyance, but the new features are way too good to have to wait for a Firefox rendering problem with *valid* html. It would be good to try to get it in the following patch release though, I think. For reference on this issue: http://kb.mozillazine.org/Incremental_reflow_bugs That page suggests that nested tables can cause them. Anyways, Confirm: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20061204 Firefox/188.8.131.52 Bugzilla (at least 2.23.2+) to HEAD; see it every day.
(In reply to comment #10) > wicked cannot with Windows 2000, nor can Tomcat with Windows XP: I'm using XP, not 2000. So I think tomcat was using Vista as it's reported as "Windows NT 5.2".
(In reply to comment #20) > (In reply to comment #10) > > wicked cannot with Windows 2000, nor can Tomcat with Windows XP: > > I'm using XP, not 2000. So I think tomcat was using Vista as it's reported as > "Windows NT 5.2". Windows NT 5.2 is in this case Windows XP x64 (it has the same Version ID (5.2.)like Windows 2003 Server :-/ Also tested again with Firefox 184.108.40.206 RC 5 on Vista and its still work for me.
Happen on FF version 220.127.116.11 too using Windows XP
I am seeing this as well when we move from 2.20 to something on the 2.23.4+ under firefox 2.0.0.x on linux, mac and windows as well as camino on mac. I noticed that this site uses an alternate skin that doesn't have a separate Details and People tables. Is the bugzilla.mozilla.org template for bug/edit.html.tmpl available? As it is now, people have to reload in order to clear it.
(In reply to comment #23) > I am seeing this as well when we move from 2.20 to something on the 2.23.4+ > under firefox 2.0.0.x on linux, mac and windows as well as camino on mac. I > noticed that this site uses an alternate skin that doesn't have a separate > Details and People tables. Is the bugzilla.mozilla.org template for > bug/edit.html.tmpl available? As it is now, people have to reload in order to > clear it. Sorry, I meant this site uses an alternate template (not skin .. global.css is customized, but yea sorry). I only caught half of my intended changes.
This was already relnoted a while ago.
Still seeing this in bugzilla 3.0 as well. Seems to happen most often after submitting changes. I saved the html of a "bad" page and compared it to the html of a "good" page and oddly, that portion of the page seemed to be identical. The only major difference was that the "bad" page had the "Changes submitted" section near the top and the heading was different. I see in Comment #19 that this is a Firefox issue. The page he links to gives suggestions for how to overcome it though.
This trick seems to fix the problem for me. The problem, from what I saw, is that the 2nd column (the one having sections "People" and "Flags") starts being displayed before the first one (the one having "Details") is completely drawn (maybe that's just me dreaming), and when the first column is made a bit wider due to new rows, the 2nd column already decided where to draw itself and doesn't move to the right despite the first column is now a bit wider. dbaron must probably laugh when reading this as it may look like a sci-fi story. ;) This patch forces the first column to be fully drawn before displaying the 2nd one, so that the horizontal position of the 2nd column is now correct. Asking GavinS, justdave and Bill for review as they could all reproduce the problem. Bill, if you don't have enough privs to set the flag, just tell me if this fixes the problem for you.
This possible test case was inspired by comment 27 and comment 15 after stumbling into a situation where I could reproduce this every time. This happened in enlightenment bugzilla. I'm not sure if it's running tip. Steps: 1. Save the attached html file locally 2. Load the file by entering the file name into the address field ==> You should see the "People" section a little over the "Details" section in a similar way as shown in attachment 255461 [details]. The test case was taken from the enlightenment bugzilla page which I saved locally. It has the code block from attachment 272498 [details] [diff] [review] inserted to the Details section of the html. Before adding it, I was not able to reproduce the problem with a static html. Refreshing by F5 will correct the page. Tested with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20070515 Firefox/22.214.171.124
Comment on attachment 272498 [details] [diff] [review] possible fix for Fx2 This looks sensible to me and is aligned with what I recall dbaron saying.
tip: Checking in template/en/default/bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.104; previous revision: 1.103 done 3.0: Checking in template/en/default/bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 126.96.36.199; previous revision: 188.8.131.52 done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.