521639 - Since landing of bug 489925 new tab button and tabs close buttons are wrongly positioned with Tabmixplus installed

Status: RESOLVED INVALID

(Firefox :: Extension Compatibility, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: screenshot

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091007 Firefox/3.5.4 (.NET CLR 3.5.30729) ID:20091007001339

Given by a report in mda.firefox we have a regression in our tabbar when Tabmixplus is installed. It started between Firefox 3.5.3 and Firefox 3.5.4 build 1. The following items are misplaced (see the screenshot):

* The new tab button is positioned at the most left side of the tabbar (left side of the scroll button if that one is visible)
* The close button of each individual tab is missing but shown as a combined button at the end of the tabbar.

A regression test on 1.9.1 nightlies turned out that bug 513394 is the culprit. Since its landing those items aren't shown in their original order anymore. That behavior is visible on all branches.

CC'ing some people so we can find out if it's our problem or something in the extension. If it's our fault other extensions could be involved too.

Comment 2

[Timothy Nikkel (:tnikkel)]

I narrowed down the regression range to either bug 489925 or bug 513394 using nightly's. Then I added bug 513394 to my old 1.9.1 debug build and could not reproduce. Then I added bug 489925 and I could reproduce the bug. These two bugs landed in the same push on all branches, so it would be impossible to distinguish between them without doing a custom build yourself. So I think this is a regression caused by bug 489925. Tabmixplus must be depending on getting anonymous nodes via getElementById or some such.

Comment 3

[Timothy Nikkel (:tnikkel)]

I wasn't able to add bug 489925 to the 'blocks' list of this bug, is that a bug? I thought you could add bugs to dependency lists that you couldn't see.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I did build my own builds depending on those two changesets. For me it was shown with the fix on bug 513394 checked-in. Sadly the same checkins happens at the same time on all branches.

As reference here the changesets:
http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=0a86b30c95ce&tochange=dd9b10ed7eeb

Comment 5

[Benjamin Smedberg]

Does TabMixPlus add elements with duplicate IDs?

Comment 6

[WildcatRay]

Also, would we be correct in assuming this is with regard to the latest production release of Tab Mix Plus (0.3.8.1)?

(Note: I have not seen this bug with recent development versions of TMP which address a number of bugs that may or may not be present in TMP 0.3.8.1 which I am using in Fx 3.5.3, Namoroka Branch and Minefield Trunk. Latest dev release available here: http://tmp.garyr.net/forum/viewtopic.php?p=37612#37612)

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #6)
> Also, would we be correct in assuming this is with regard to the latest
> production release of Tab Mix Plus (0.3.8.1)?

Yes, testing always happens with the latest official version.

> (Note: I have not seen this bug with recent development versions of TMP which
> address a number of bugs that may or may not be present in TMP 0.3.8.1 which I

Thanks for the link. I'm not able to see this in a developer version of TMP too. Looks like that v0.3.8.1 really adds elements with duplicate id's?

Comment 8

[WildcatRay]

(In reply to comment #7)
> (In reply to comment #6)
> > Also, would we be correct in assuming this is with regard to the latest
> > production release of Tab Mix Plus (0.3.8.1)?
> 
> Yes, testing always happens with the latest official version.
> 
> > (Note: I have not seen this bug with recent development versions of TMP which
> > address a number of bugs that may or may not be present in TMP 0.3.8.1 which I
> 
> Thanks for the link. I'm not able to see this in a developer version of TMP
> too. Looks like that v0.3.8.1 really adds elements with duplicate id's?

Your welcome.

FYI: I was about to post that v0.3.8.2 was just released today, but when I checked AMO, again, it appears to have reverted back to v0.3.8.1. Checking a third time, and v0.3.8.2 is posted, again.

You may want to talk with onemen regarding the use of elements with duplicate IDs. Hopefully, there is a way to work this out so that future issues can be avoided.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Ok, version 0.3.8.2 of Tabmixplus fixes all the given issues from comment 0.

Does it mean that whenever it is not working for an extension in Firefox 3.5.4 it's an extensions fault and we don't care about? If that's the case we should move this bug to extension compatiblity and close it as invalid.

Comment 10

[Benjamin Smedberg]

It's a case-by-case decision, but in this case we have a fixed version of the extension and we know the cause (an extension caused duplicate IDs, which is undefined behavior). So WONTFIX in this case.

Comment 11

[Houston Staton]

I must clarify, some time ago I installed version 0.3.7.4pre090516 of Tab Mix Plus.  This version was never updated automatically either on the Mac side of my laptop where I was having the problems as described or on the Windows Vista Side.  I updated to version 0.3.8.2 on the Mac and the problem was resolved.  The extension information window on my FF browser indicated prior to the update that it was having problems updating the version annotated above.  On the Vista side the version remains without a mention of the bug reported.  I will update to latest version on the Vista side as well.  The bug then becomes those that have version 0.3.7.4pre090516 installed, as automatic updates will never take place as it stands.

Comment 12

[Daniel Veditz [:dveditz]]

(In reply to comment #9)
> Does it mean that whenever it is not working for an extension in Firefox 3.5.4
> it's an extensions fault and we don't care about?

If a security update breaks an extension or web site our first assumption must be that it's Firefox's fault--users will certainly assume that. Sometimes it really is a regression that we need to fix before release because the one case we noticed during the pre-release period was just the tip of the iceberg. Sometimes the breakage is unavoidable because the site or extension was unintentionally relying on a security bug, and in those cases we need to work with the addon or site authors so our shared users don't have a bad upgrade experience.

As Benjamin says it's case-by-case, but the important thing is that we investigate quickly and understand the cause.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thanks Daniel. I'll continue to check newsgroups and other channel if other add-ons suffer from the same change.