Bug 467867 (SMtabAPI)

[META] Implement Firefox TabBrowser API in Seamonkey

NEW
Unassigned

Status

SeaMonkey
Tabbed Browser
--
enhancement
9 years ago
6 years ago

People

(Reporter: D, Unassigned)

Tracking

({meta})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
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...
(Reporter)

Updated

9 years ago
Version: unspecified → Trunk
not sure if this is practical now, but wait for a dev...

Comment 2

9 years ago
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.
Blocks: 460960
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

9 years ago
> 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.

Comment 5

9 years ago
We aren't talking about the UI, just the APIs so that Firefox extensions could be more easily ported over.
(Reporter)

Comment 6

8 years ago
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).

Comment 7

8 years ago
Lets turn this into a meta bug and file separate dependent bugs for each specific issue.
Summary: Implement Firefox TabBrowser API in Seamonkey → [META] Implement Firefox TabBrowser API in Seamonkey

Updated

8 years ago
Depends on: 482291

Updated

8 years ago
No longer depends on: 482291
Keywords: meta

Updated

8 years ago
Depends on: 482291

Comment 8

7 years ago
Misak, you said you might want to look into this?
Flags: wanted-seamonkey2.1?

Comment 9

7 years ago
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.
Depends on: 554908
Depends on: 558614
Depends on: 558673

Updated

7 years ago
No longer depends on: 554908

Updated

7 years ago
Depends on: 554908

Updated

7 years ago
Alias: SMtabAPI

Comment 10

7 years ago
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.

Comment 11

7 years ago
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.

Comment 12

7 years ago
(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?

Comment 13

7 years ago
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.

Comment 14

7 years ago
(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.

Updated

7 years ago
Depends on: 558995

Comment 15

7 years ago
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 ;)

Updated

7 years ago
status-seamonkey2.1: --- → wanted
Flags: wanted-seamonkey2.1?
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.

Updated

7 years ago
Depends on: 570783

Updated

7 years ago
Depends on: 570791
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.

Comment 23

7 years ago
.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.

Comment 25

7 years ago
(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.

Comment 27

7 years ago
(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.

Comment 29

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

Updated

7 years ago
Depends on: 570981
(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!]

Updated

7 years ago
Depends on: 573733

Updated

7 years ago
Depends on: 577756

Updated

7 years ago
Depends on: 579845

Updated

7 years ago
Depends on: 586340
No longer depends on: 562649

Updated

7 years ago
Blocks: 595483

Updated

7 years ago
No longer blocks: 595483
Depends on: 595483

Updated

7 years ago
Depends on: 484968

Updated

7 years ago
Depends on: 609034

Updated

6 years ago
Depends on: 633121
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!
status-seamonkey2.1: wanted → ---

Comment 32

6 years ago
Bug 570981 is a firefox bug.
You need to log in before you can comment on or make changes to this bug.