Last modified: 2014-11-17 09:21:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3629, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1629 - Section edit links showing up in wrong place
Section edit links showing up in wrong place
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal minor with 29 votes (vote)
: ---
Assigned To: Aryeh Gregor (not reading bugmail, please e-mail directly)
http://en.wikipedia.org/wiki/Wikipedi...
:
: 2703 4523 5148 6213 6713 6963 9478 10993 12662 19365 21614 22864 24873 26198 (view as bug list)
Depends on:
Blocks: editlinks
  Show dependency treegraph
 
Reported: 2005-03-04 02:50 UTC by SPUI
Modified: 2014-11-17 09:21 UTC (History)
28 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Non-Javascript implementation of "German solution" (2.25 KB, patch)
2006-08-08 17:06 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details
html from [[WP:BUNCH]] using div with negative relative position for section edit link (6.18 KB, text/html)
2007-01-03 02:51 UTC, Rick Block
Details
Partial patch (doesn't work for non-Monobook-based) (4.05 KB, patch)
2007-01-08 02:41 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details

Description SPUI 2005-03-04 02:50:48 UTC
When I view http://en.wikipedia.org/wiki/User:SPUI/RI_10 in a Mozilla-based
browser (Firefox, K-Meleon, etc) some of the edit links are in the wrong place -
see http://en.wikipedia.org/wiki/Image:Fucked_edit_links.png for a screenshot. A
possibly related but very minor problem occurs in the latest version of Internet
Explorer - see http://en.wikipedia.org/wiki/Image:IE_SPUI_R10.gif .

The fact that this only happens in certain browsers suggests that it may be a
browser problem; if this is found to be the case, can someone with more
knowledge of the cause submit it as a Mozilla bug? It could also be a CSS issue,
with different browsers parsing it differently; or it could be a browser problem
but fixable by changing the CSS.
Comment 1 Zigger 2005-06-06 13:36:18 UTC
In [[Boston_College]], this can be seen with Firefox 1.04 but not IE6-SP1, and
is associated with misplacement of left-aligned thumbnails.
Comment 2 Zigger 2005-07-17 14:01:00 UTC
See also bug 72 and bug 2703.
Comment 3 Brion Vibber 2006-01-07 19:47:33 UTC
*** Bug 4523 has been marked as a duplicate of this bug. ***
Comment 4 Brion Vibber 2006-01-07 19:47:47 UTC
*** Bug 2703 has been marked as a duplicate of this bug. ***
Comment 6 lɛʁi לערי ריינהארט 2006-02-05 14:06:14 UTC
Not shure if this is the same bug at [[ro:user:Gangleri#bugzilla_01629]] where
four [[ro:MediaWiki:Editsection]] are shown.

Using
Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.0.1) Gecko/20060111
Firefox/1.5.0.1

best regards reinhardt [[user:gangleri]]
Comment 7 baumanns 2006-02-07 11:08:47 UTC
Someone in the German Wikipedia has written a short JavaScript file. This puts
the 'edit' text to the left side instead of the right. Try it if you're using a
Mozilla browser (copy&paste into your monobook.js).

function moveEditsection() {
	var editsections = new Array();
	var divs = document.getElementById("bodyContent").getElementsByTagName("div");
	for(var i = 0; i < divs.length; i++) {
		if(divs[i].className == "editsection") {
			editsections.push(divs[i]);
		}
	}
	if (editsections.length != 0) {
		var i = 0;
		var element, heading;
		while (editsections[i] != null) {
			element = editsections[i];
			heading = element.nextSibling;
			while(!/^H[2-6]$/.test(heading.nodeName)) {
				heading = heading.nextSibling;
			}
			var spanElement = document.createElement("span");
			var spaceNode = document.createTextNode(" ");
			heading.appendChild(spaceNode);
			heading.appendChild(spanElement);
			spanElement.style.fontSize = "x-small";
			spanElement.style.fontWeight = "normal";
			while (element.childNodes.length != 0) {
				spanElement.appendChild(element.childNodes[0]);
			}
			element.parentNode.removeChild(element);
			i++;
		}
	}
}
aOnloadFunctions[aOnloadFunctions.length] = moveEditsection;
Comment 8 Lupin 2006-02-07 13:27:10 UTC
Is it worth creating a user preference to put edit section links on the left (or
the right for RTL languages)? I would expect this to be be relatively
straightforward.
Comment 9 Timothy Martin 2006-02-20 07:43:38 UTC
This can be seen on the page [[Artemis]]
Comment 10 lɛʁi לערי ריינהארט 2006-02-20 13:07:16 UTC
(In reply to comment #9)
> This can be seen on the page [[Artemis]]

[[ro:user:Gangleri#contributions]] shows more misplaced edit section links. Is
it possible using another HTLM / CSS implementation to "force" that section
headers and edit section links apear on the same line (inside the <p>... </p>)?

<p><a name="Contribu.C5.A3ii" id="Contribu.C5.A3ii"></a></p>
<h2><font id="contributions"></font>Contribuţii</h2>
Comment 11 Melancholie 2006-03-22 01:23:00 UTC
*** Bug 5148 has been marked as a duplicate of this bug. ***
Comment 12 Matthias Binninger 2006-05-20 13:47:31 UTC
(In reply to comment #7)
> Someone in the German Wikipedia has written a short JavaScript file. 
This one is from me. More details (German...) can be found at
http://de.wikipedia.org/wiki/Benutzer:Dbenzhuser/Monobook
I know, that several people use it and like the alternative position of the
editsection link. So I could imagine this to be a solution for the problem (of
course built-in to the mediawiki php code, not js)

PS: The last line should be changed from
> aOnloadFunctions[aOnloadFunctions.length] = moveEditsection;
to
> addOnloadHook(moveEditsection);
to work properly in others than only the German-speaking wikipedia.
Comment 13 baumanns 2006-07-02 21:28:28 UTC
*** Bug 6213 has been marked as a duplicate of this bug. ***
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-07-17 18:14:15 UTC
*** Bug 6713 has been marked as a duplicate of this bug. ***
Comment 15 Matthias Binninger 2006-07-21 14:23:31 UTC
In the german wikipedia we have currently enabled a slightly modified version of
the script from above for all users.
Even though there are demurs which are discussed at the moment, the overall
reactions aren't that bad.

Disadvantages of a sollution using JavaScript are
1) that it's JavaScript (including on old machines/long pages a visible
switching of the buttons)
2) that there is no possibility to configure it by the preferences dialog
(deactivating is currently only possible by the own monobook.js)

Would be great, if a developer could check if the behaviour can be integrated in
the MediaWiki-Code (with a possibility to return to standard behaviour by the
preferences). This would solve this bug.
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-07-21 19:26:02 UTC
After doing a bit of delving into CSS specifications, the relevant specification
is point 5 at http://www.w3.org/TR/CSS21/visuren.html#float-position, "The outer
top of a floating box may not be higher than the outer top of any block or
floated box generated by an element earlier in the source document."  What this
means is that if any content within a section is floated right, any section edit
links will not be able to be above the top of that content.  This is irrelevant
for a single right float, since its top must be within the preceding section,
but if a second right float is present, the position of the edit link may be
shoved down.

As far as I can think of, there's no possible fix that doesn't cause problems of
its own.  The <div> trick given at the new URL can't be automated, because
floated images would then be positioned one on top of another, which would not
be the desired effect if a right-floated image were placed near the top of a
section, then another several paragraphs later.  We don't know how tall the
lines are going to be rendered, so we can't determine whether an image is going
to overflow into the next section.  We could just clear every section, but
that's unacceptable.

When I get around to it, I'll see if I can ask some CSS gurus if they have any
ideas.

(In reply to comment #15)
> Would be great, if a developer could check if the behaviour can be integrated in
> the MediaWiki-Code (with a possibility to return to standard behaviour by the
> preferences). This would solve this bug.

Well, it would brush it under the carpet.  First of all you'd have edit links on
the left instead of the right, which isn't necessarily desirable, and second of
all it would still screw up on left floats (which just happen to be less common
in LTR languages).
Comment 17 Matthias Binninger 2006-07-22 10:53:19 UTC
(In reply to comment #16)

> Well, it would brush it under the carpet. First of all you'd have edit links on
> the left instead of the right, which isn't necessarily desirable, and second of
> all it would still screw up on left floats (which just happen to be less common
> in LTR languages).

Having them on the left side (not completely on the left, just right next to the
heading) in my eyes is just a matter of habit. As this sollution does not use
float to position the links, there is no problem with images or floated tables,
not matter where they are. Just look on any page of the german wikipedia. Of
course not everybody likes it, but a lot do - and it solves other usability
problems, too.
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-07-23 19:48:45 UTC
(In reply to comment #17)
> Having them on the left side (not completely on the left, just right next to the
> heading) in my eyes is just a matter of habit. As this sollution does not use
> float to position the links, there is no problem with images or floated tables,
> not matter where they are.

Er, right.  My bad.  So that could be a solution, yes, and it would also put
more emphasis on the edit links (which is presumably good).
Comment 19 jd 2006-08-08 14:26:18 UTC
I support having the deutsch behavior enabled by default. In fact, the script is
a workaround for a problem that could have been solved easily in Monobook.css,
if there was no automated generation of <div class="editsection"
style="float:right;margin-left:5px;"> by MediaWiki (it's the static style
statement that is the issue here). What about getting rif of the style statement
here and moving it in Monobook.css?
Comment 20 Matthias Binninger 2006-08-08 15:04:06 UTC
(In reply to comment #19)
The style part can easily be overwriten in the monobook.css by using the
!important statement to increase its priority:

.editsection {
    float:none !important;
    margin-left:0 !important;
}

But I don't see how you want to achieve the current behavior of the german
wikipedia by only using css. The problem - thats why I used JS - is the order in
which the parts (link and heading) are written in the html code. Afaik there is
no way changing this with css.
Comment 21 jd 2006-08-08 15:06:54 UTC
Indeed, my mistake. Anyway, I support this bug :)
I've just made the fr wikipedia switch to this behavior (like on de), so we will
have more feedback.
Comment 22 Matthias Binninger 2006-08-08 15:58:08 UTC
(In reply to comment #21)

> I've just made the fr wikipedia switch to this behavior

I don't know how much people use it, but there is a known bug:
The "section editing by right-clicking on section titles" doesn't work together
with the modified edit links. The right-click-script workes pretty similar as
moveEditsection(): It searches the edit links and then modifies the following
heading. As moveEditsection() changes the structure of this part of the page,
the right-click-script fails.

Just if others run with the idea to use the script, be prepared that there still
can/will be little problems.
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-08 17:06:30 UTC
Created attachment 2204 [details]
Non-Javascript implementation of "German solution"

This patch tweaks the PHP files to implement a solution that's basically
identical to what the Germans and French now use, but without that icky
Javascript.  This should work for any skin, but note that it puts the
editsection link inside the h# tag, so they'll be the same size and general
appearance as the header in any skin other than Monobook (whose CSS I tweaked
in the patch).

I'm still slightly skeptical of whether the general solution should be
implemented in the software at all, but it's true that that looks to be the
only way to reliably solve this bug until CSS improves.  One other way to solve
many of the cases where it occurs would be to have consecutive images floated
in the same direction be put inside a floated div instead of being individually
floated.
Comment 24 Rotem Liss 2006-08-09 18:35:10 UTC
*** Bug 6963 has been marked as a duplicate of this bug. ***
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-18 06:57:31 UTC
Comment on attachment 2204 [details]
Non-Javascript implementation of "German solution"

Patch is obsolete with r17078.	A replacement patch should be easy: all style
changes are in place, so just swap the order of the spans in Parser.php.
Comment 26 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-22 03:47:40 UTC
Provided we want to maintain current float behavior, this bug is unfixable until
CSS improves.  Changing floated section edit links to inline is a separate request.
Comment 27 Rick Block 2007-01-02 04:16:10 UTC
Instead of floating it, how about putting it in a right aligned div with a negative relative top position?  The heading would 
need to have a right margin added to ensure a blank spot to put it in.  See example at http://en.wikipedia.org/wiki/
Wikipedia:Village_pump_%28technical%29#This_edit_link_floating_image_CSS_bug_has_been_around_for_EVAR .
Comment 28 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-02 05:13:38 UTC
Positioning something to look like it's on the previous line is not generally
possible with CSS 2.1, since you have access to only the font-size of the
current element and not its line-height.  You mostly have to hardcode the
line-height, which will screw up if anyone changes it.  But that aside, please
post a working HTML example here as an attachment.  Just take some standard
thing that has edit links bunched up from [[WP:BUNCH]], and restyle the edit
links according to your scheme so that they don't bunch.  I can then review it
and commit it if it works well.
Comment 29 Rick Block 2007-01-03 02:51:32 UTC
Created attachment 3004 [details]
html from [[WP:BUNCH]] using div with negative relative position for section edit link

I'm not claiming it's perfect, but I've attached a version of [[WP:BUNCH]]'s
example 1 using a div with a negative relative position (to get the edit link
on the right line).  I've only looked at this in two browsers (IE7 and Safari).
  This probably needs a change to the header style to make sure there's a blank
spot on the line (like a 6 or 7 em right margin).  The only thing I'm really
claiming is that this might be worth taking a look at.
Comment 30 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-03 05:07:36 UTC
That appears to display quite well.  I'll look into it tomorrowish.
Comment 31 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-08 02:41:15 UTC
Created attachment 3031 [details]
Partial patch (doesn't work for non-Monobook-based)

This appears to work without a hitch.  It involves document structure changes,
however, so there will have to be notifications and so on so people can make
sure their scripts and stuff won't spontaneously combust.
Comment 32 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-02 15:17:09 UTC
*** Bug 9478 has been marked as a duplicate of this bug. ***
Comment 33 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-02 15:22:07 UTC
Okay, here's the reason I haven't committed this yet.  It's passed every test I've put it to, but I'd 
bet five bucks that some corner case is going to screw it up just as badly as the current floating is 
screwed up.  And while that may or may not happen, if it *does* happen, it will mean that I've 
disrupted everyone's scripts and CSS for no good reason.  It also may require reversion of the 
changes, causing more disruption.

And finally, according to that usability study (Google for it), people are totally confused by edit 
links being all the way to the right anyway.  They think they belong to the previous section, because 
after all, there's this big line under them separating them from the section below.  Edit links should 
be changed to look like the German and French Wikipedias have them, or else to be on the left rather 
than the right (so they don't jump around).  That will eliminate this problem, and in all likelihood 
improve usability generally.  So I'd be inclined to do that rather than this.  It won't even require 
document structure changes, just CSS changes, so nothing breaks.
Comment 34 Wolf Peuker 2007-06-07 09:20:14 UTC
It would be great to have the german Wikipedia behavior by default:
DOM order wm-headline, editsection.
Comment 35 Wolf Peuker 2007-06-14 09:25:13 UTC
(In reply to comment #7)
> Someone in the German Wikipedia has written a short JavaScript file. This puts
> the 'edit' text to the left side instead of the right. Try it if you're using a
> Mozilla browser (copy&paste into your monobook.js).
> 

Would it be possible to bring this monobook.js snippet to work with IE7 too, maybe to skip it only as to keep the en:WP look?
Comment 36 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-26 01:47:58 UTC
(In reply to comment #33)
> And finally, according to that usability study (Google for it), people are
> totally confused by edit links being all the way to the right anyway.  They
> think they belong to the previous section, because after all, there's this big
> line under them separating them from the section below.  Edit links should
> be changed to look like the German and French Wikipedias have them, or else to
> be on the left rather than the right (so they don't jump around).  That will
> eliminate this problem, and in all likelihood improve usability generally.  So
> I'd be inclined to do that rather than this. It won't even require document
> structure changes, just CSS changes, so nothing breaks.

I'm ready to do this; see <http://lists.wikimedia.org/pipermail/wikitech-l/2007-June/031899.html> ff.  Please comment if you have an opinion.

Comment 37 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-16 15:51:20 UTC
In the midst of all the discussion, which is still ongoing and which I'm still committed to finishing off, I realized that there's a very simple way to do this, with a one-line CSS change.  I've had it in my Wikipedia CSS for a while now and have seen no issues.  I think it very likely that this will fix the problem once and for all, so I'm resolving FIXED in r24168.
Comment 38 Rotem Liss 2007-07-18 20:52:12 UTC
It was reverted in r24253 and r24254: it broke RTL on Firefox and also broke IE/Mac.
Comment 39 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-18 22:11:21 UTC
What was the breakage on IE/Mac?  RTL I can look at, IE/Mac not so easily.  It could just be hidden from IE/Mac, though.
Comment 40 Brion Vibber 2007-07-19 13:50:15 UTC
Header text was invisible.
Comment 41 Danny B. 2007-08-19 17:39:35 UTC
*** Bug 10993 has been marked as a duplicate of this bug. ***
Comment 42 Omegatron 2007-09-10 00:23:08 UTC
(In reply to comment #33)
> And finally, according to that usability study (Google for it),

This?

http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt_Usability/Test_Februar_2006

> people are
> totally confused by edit 
> links being all the way to the right anyway.

Then they should not be all the way to the right.  Making the headers display:table; kind of works.  Kind of.   German Wikipedia looks better, though.
Comment 43 Erik Baas 2007-11-06 00:15:43 UTC
The bug now also shows in Opera (8.02), see for example http://nl.wikipedia.org/w/index.php?title=Circuit_Park_Zandvoort&diff=10057985&oldid=10056982 . Maybe someone shoud do something about it, after all the bug was reported 32 months ago. :-(
Comment 44 Erik Baas 2007-11-10 23:01:20 UTC
A much better example is on http://nl.wikipedia.org/wiki/Gebruiker:Erik_Baas/1629 .
Comment 45 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-21 18:27:22 UTC
Other bugs related to section edit link formatting: bug 11270, bug 11555.
Comment 46 Tisza Gergő 2007-12-21 20:07:14 UTC
Not very elegant, but works for Firefox 2:

.editsection {
  float: none;
  display: block;
  text-align: right;
  position: relative;
  bottom: 1em;
  line-height: 0; /* alternatively, you could use a negative margin */
}

It assumes edit links are *after* the headlines, thus it would solve bug 11555 too. On the other hand, it would probably make the tab-like appearance proposed in bug 11270 impossible.
Comment 47 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-21 20:17:16 UTC
The question is whether the margins could be worked out accurately for all browsers and fonts.  If so, something like that would be workable.  I plan to put some effort into it over the next week or so, with the tabs too.  (Tabs would work fine with that code, you just have to work in a background, padding, and some borders.)

I think absolute positioning would actually work better than relative.  The question is whether all browsers we support (which I guess is IE5+/Windows, IE5/Mac, Mozilla and Firefox 1.0+, Opera 7+, some versions of Safari; or some list like that) will behave correctly.  I suspect they might not, based on comment 40 here, but the idea should be the same as for the content tabs, so I'm optimistic that I can look into the hacks we use for that and adapt them if I give it some effort.  It would be good if I could dig up a Mac, but failing everything else, just omitting the tabs or fancy positioning for some browsers would be acceptable.
Comment 48 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-26 03:11:57 UTC
Oddly enough . . . I can't reproduce this locally.  [[WP:BUNCH]] shows up correctly for me.  Can anyone else reproduce this bug at this point?  If not, I'm going to have to call it FIXED.  I'll continue discussion on reformatting at bug 11270.
Comment 49 Tisza Gergő 2007-12-26 09:03:11 UTC
I still see it at WP:BUNCH (FF 2.0.0.11/Win XP).
Comment 50 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-26 13:47:20 UTC
Ah, I had a custom CSS rule, never mind.  Stupid of me.  I plan to fix this along with bug 11270, anyway.
Comment 51 Danny B. 2008-01-17 16:29:43 UTC
*** Bug 12662 has been marked as a duplicate of this bug. ***
Comment 52 Robert Ullmann 2008-06-17 16:33:28 UTC
Wow! Such complex solutions to a simple problem: the header is not "containing" the float-right [edit] link.

Add to the .css:

 <nowiki>
/* make headers include contained floats, so they don't wander around (yes, is magic, it tells the browser the tag is a container) */

h1, h2, h3, h4, h5, h6 {
	overflow: hidden;
	width: auto;
        }
/* keep "[edit]" at normal font, not inherit header attributes */
.editsection {
	font-size: 100%;
	font-weight: normal;
        }
</nowiki>
Comment 53 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-17 16:42:18 UTC
Please read previous comments before posting new ones.  This was tried in comment #37, but was backed out because of issues with RTL and IE5/Mac.  If you can submit a modified set of rules that addresses those issues, I'll commit them.  In any event, the "width" rule there should have no effect and should be omitted; and the .editsection rule is completely mysterious (why should setting overflow: hidden require any changes to editsection size or weight?).
Comment 54 Robert Ullmann 2008-06-17 16:59:50 UTC
Sorry, that comment didn't say *what* was tried ... (yes, I know by chasing all the rNN links I would have found it), sorry again.

The width: auto; seems to be needed for it to work in some browsers/versions. In any case, harmless.

The .editsection code is needed because the link is now "inside" the header, and will appear bolded and at different sizes as with the headers. (probably not desirable, in any case not the status quo ante)
Comment 55 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-06-17 17:50:09 UTC
(In reply to comment #54)
> The width: auto; seems to be needed for it to work in some browsers/versions.

What browsers?

> The .editsection code is needed because the link is now "inside" the header,
> and will appear bolded and at different sizes as with the headers. (probably
> not desirable, in any case not the status quo ante)

No change to CSS can change the inheritance of CSS properties.  The link is inside the header already, and that code is already present in main.css, line 128 ff.  (Except that there it actually works: font-size: 100% means "set the font size to the same as the parent's font size", which is not what you want.)  Why is your version of the code relevant here at all?
Comment 56 Chris R. 2009-06-01 04:49:01 UTC
Just FYI, English Wikipedia is considering moving the [edit] links to just after the section titles (like German Wikipedia) in order to fix the bunching problem. Apparently this would require bug 11555 to be fixed.
See http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#The_.5Bedit.5D_link_for_sections
Comment 57 Chad H. 2009-06-23 22:13:44 UTC
*** Bug 19365 has been marked as a duplicate of this bug. ***
Comment 58 Alexandre Emsenhuber [IAlex] 2009-11-25 12:09:54 UTC
*** Bug 21614 has been marked as a duplicate of this bug. ***
Comment 59 Derk-Jan Hartman 2010-03-17 20:16:57 UTC
*** Bug 22864 has been marked as a duplicate of this bug. ***
Comment 60 entlinkt 2010-07-23 22:00:42 UTC
Related to bug 8814.
Comment 61 Bawolff (Brian Wolff) 2010-08-19 19:54:46 UTC
*** Bug 24873 has been marked as a duplicate of this bug. ***
Comment 62 Chad H. 2010-12-02 19:34:44 UTC
*** Bug 26198 has been marked as a duplicate of this bug. ***
Comment 63 Erwin Dokter 2011-01-29 21:06:44 UTC
Fixed in r79087 via bug 26449.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links