User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081203 Lightning/0.6a1 SeaMonkey/2.0a3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081203 Lightning/0.6a1 SeaMonkey/2.0a3pre Firefox tabbrowser API(s) needs to be implement SeaMonkey. More extension will be compatible with Seamonkey because of tab menu and behavior of tabs. We could use various extensions for behavior of tabs ... Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: ...for now we have that we can't use no-one extension for rule tabs...

not sure if this is practical now, but wait for a dev...

Basically, I kind of need this to base tabmail upon: tabmail uses a bunch of prefs stolen and renamed from the FF tabbrowser implementation. We _could_ implement whacky mappings from our tabbrowser prefs to the ones used/needed by tabmail, but I think tabbrowser has some modifications worthwile to take over, eg. close button prefs and open tab list. Marking as blocking the tabmail, but that's not a hard block - tabmail works perfectly without it, just the pref defaults are missing, causing odd default sizing.

> Marking as blocking the tabmail, but that's not a hard block - tabmail works > perfectly without it, just the pref defaults are missing, causing odd default > sizing. I'd suggest filing a more specific bug about the firefox tabbrowser prefs. This should be a meta/tracking bug instead.

Not sure I like the direction the Fx tabbrowser is evolving. OTOH it would of course facilitate maintenance to have only one tabbrowser subsystem rather than two, and maybe it would even allow using the Tab Mix Plus extension (one of my Fx must-haves) with SeaMonkey.

We aren't talking about the UI, just the APIs so that Firefox extensions could be more easily ported over.

It's almost what you want, Tony. TabMixPlus should work with FF tabbrowser API calls(may be with some modification). And anyone knows should need to port FF UI or part of UI to SM ? like examle: Does SM UI support vertical&horizontal scrollbars in tab aria ? (like supports in TabKit extension).

Lets turn this into a meta bug and file separate dependent bugs for each specific issue.

Misak, you said you might want to look into this?

Yes, but it's not a high priority for me. First i want to implement mailnews sessionstore, keep parity with firefox sessionstore (there is a bunch of patches waiting to port), and then tabbrowser API. If it should be done at specific time, i can't guarantee that, otherwise I'll work on it.

https://developer.mozilla.org/en/XUL/tabbrowser has a documentation of much of the public API, I guess we should try to implement the items listed there, as that's as close to a public API doc as it gets.

I checked both tabbrowser implementations, we miss 3 methods - loadOneTab, loadTabs and selectTabAtIndex. addTab have parameter differences, all others in sync. Bug 558614 for loadTabs, where i fixed all mentioned stuff above, except selectTabAtIndex. The last should be very easy. I'll do it in separate bug.

(In reply to comment #11) > I checked both tabbrowser implementations, we miss 3 methods - loadOneTab, > loadTabs and selectTabAtIndex. What about things like getIcon() or the tab progress listeners?

Tab progress listeners are waiting for checkin, regarded getIcon() - I've checked only methods listed in https://developer.mozilla.org/en/XUL/tabbrowser. If someone gets a list of other useful methods, I'll port them too.

(In reply to comment #13) > I've > checked only methods listed in https://developer.mozilla.org/en/XUL/tabbrowser. Ah, I parsed "I checked both tabbrowser implementations" wrongly, then. I thought you looked at both tabbrowser.xml files and compared them.

I did cat mozilla/browser/base/content/tabbrowser.xml | grep "method name" -A 10 for both files and looked to parameters, but didn't carefully examined methods not listed in the wiki. But they look very similar. So - just give me the list ;)

Is gBrowser.addTabsProgressListener fully implemented currently in the Trunk? The reason I ask is that while I am getting most of the listener callbacks mentioned on https://developer.mozilla.org/En/Listening_to_events_on_all_tabs I am not getting the onLinkIconAvailable one. I don't know if that means it's simply not being called or link icons are never loading. I think it might be the later since I'm noticing that icons aren't displaying in tabs for most web sites.

Certainly if you don't see the link icon for a site then you won't get the notification either ;-) Could the problem be a conflict with another addon? Do you see the link icons when running in safe mode?

Safe mode doesn't seem to be working (-safe-mode parameter doesn't do anything) so I created a new profile and icons aren't loading for a number of sites in that one either. For example http://www.google.com doesn't load an icon, but http://www.seamonkey-project.org/start/ does. This isn't limited to the trunk load, I see the same thing in SeaMonkey 2.0.4 and 2.0.6pre. I'm guessing that's a different issue then. I decided to do some digging into the tabbrowser.xml code (http://mxr.mozilla.org/comm-central/source/suite/browser/tabbrowser.xml#355) and found that it is not calling onRefreshAttempted or onLinkIconAvailable for this.mTabBrowser.mTabsProgressListeners stored in tabbrowser.xml. All the other TabProgressListener callbacks are called. onRefreshAttempted needs to be added around line 642 (in onRefreshAttempted function) and onLinkIconAvailable needs to be added around line 648 (in setIcon function).

(In reply to comment #18) > Safe mode doesn't seem to be working (-safe-mode parameter doesn't do anything) > so I created a new profile and icons aren't loading for a number of sites in > that one either. For example http://www.google.com doesn't load an icon, but > http://www.seamonkey-project.org/start/ does. This isn't limited to the trunk > load, I see the same thing in SeaMonkey 2.0.4 and 2.0.6pre. I'm guessing > that's a different issue then. We only call onLinkIconAvailable for link icons. Google uses a favicon. > I decided to do some digging into the tabbrowser.xml code > (http://mxr.mozilla.org/comm-central/source/suite/browser/tabbrowser.xml#355) > and found that it is not calling onRefreshAttempted or onLinkIconAvailable for > this.mTabBrowser.mTabsProgressListeners stored in tabbrowser.xml. All the > other TabProgressListener callbacks are called. Actually onRefreshAttempted seems to be called twice on the progress listeners instead of once on the progress listeners and once on the tabs progress listeners. That's a bug, and thanks for finding it. Do you want to file it? > onRefreshAttempted needs to be added around line 642 (in onRefreshAttempted > function) and onLinkIconAvailable needs to be added around line 648 (in setIcon > function). Sure, but I think the existing notification should also move there too.

I guess I could file it. Should I include the part about the missing onLinkIconAvailable for tab progress listeners as well or should that be separate?

(In reply to comment #20) > I guess I could file it. Should I include the part about the missing > onLinkIconAvailable for tab progress listeners as well or should that be > separate? It should be separate, since the refresh bug is trivial by comparison.

Okay the onRefreshAttempt bug is bug 570783. The onLinkIconAvailable bug is bug 570791. This will probably require gBrowser.setIcon() to be implemented, which would be a separate bug.

.setIcon() is already in bug 554908.

(In reply to comment #23) > .setIcon() is already in bug 554908. So it is. Looks like the onLinkIconAvailable code is commented out though so I guess bug 570791 is still valid. Actually it looks like you could kill two bugs with one stone, if you moved the code from setIcon and updateIcon into mTabProgressListener.setIcon(). I'll comment about the specifics in bug 554908.

(In reply to comment #24) > So it is. Looks like the onLinkIconAvailable code is commented out though That's just because .mTabsProgressListeners was not implemented on the suite side yet when I created the patch. Now, it can just be left in as it should be.

(In reply to comment #25) > That's just because .mTabsProgressListeners was not implemented on the suite > side yet when I created the patch. Now, it can just be left in as it should be. It still won't work as currently written though because .mTabsProgressListeners isn't implemented exactly the same way it is in Firefox. See my reply in bug 554908.

(In reply to comment #26) > It still won't work as currently written though because .mTabsProgressListeners > isn't implemented exactly the same way it is in Firefox. Then that cause is the bug. We ought to be implementing the same API as Firefox or this very bug here is useless.

(In reply to comment #27) > Then that cause is the bug. We ought to be implementing the same API as Firefox > or this very bug here is useless. From looking at the code, it looks like the API will work the same, it's just the implementation that's different.

Bug 562649 set and correctly handle userTypedValue when loading external URIs http://hg.mozilla.org/mozilla-central/rev/f2070673fdbc

(In reply to comment #11) > I checked both tabbrowser implementations, we miss 3 methods - loadOneTab, > loadTabs and selectTabAtIndex. addTab have parameter differences, all others in > sync. Bug 558614 for loadTabs, where i fixed all mentioned stuff above, except > selectTabAtIndex. The last should be very easy. I'll do it in separate bug. Care to file it? :-) [Big thanks for your work BTW!]

Sooo... do we intend to continue along with this meta bug, or do we want to resolve as fixed. All deps are fixed by now!

Bug 570981 is a firefox bug.