[Ext] Tab Utilities 1.5 - light but featureful

Announce and Discuss the Latest Theme and Extension Releases.
Post Reply
User avatar
braveheartleo
Posts: 43
Joined: September 22nd, 2007, 3:27 am

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by braveheartleo »

ithinc wrote:"Paste and Go" shortcut = Open from Location Bar
"Paste and Search" shortcut = Open from Search Bar
So you may control their behaviors by changing the new tab options for Location Bar and Search Bar.

For the tab context menu item, it is scriptable. You can open anywhere if you like.
Open in new tab always:

Code: Select all

gBrowser.loadURLFromClipboard();

Open in the current tab:

Code: Select all

gBrowser.loadURLFromClipboard(gBrowser.mCurrentTab);

Open in the context tab or new tab if tab bar clicked:

Code: Select all

gBrowser.loadURLFromClipboard(document.popupNode.localName == "tab" ? gBrowser.mContextTab : null);

Thank you for providing other possible code customizations.
DarkOne123
Posts: 383
Joined: December 28th, 2004, 10:17 pm

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by DarkOne123 »

I've set New Tab to be my home page (which is Google.com) however when I click New Tab. In the address bar I still see "Search Bookmarks and history" this wasn't really a problem until the Google Instant Search came out which doesn't work when you click New Tab.
User avatar
ben_r_
Posts: 4
Joined: December 5th, 2010, 2:10 pm
Location: Sacramento, CA
Contact:

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by ben_r_ »

ithinc wrote:
ben_r_ wrote:To what value? I have it up to 200 to 250 now.

Then if you have tabs narrower than 200px, you have other extensions/scripts/styles working. It should be an extension conflict.

Thats the thing. I am trying this extension on THREE computers, two brand new Macs and one PC. On the Macs, this is the ONLY extension running. Something is very odd here...
If at first you don't succeed, redefine success!
bolobb
Posts: 94
Joined: April 25th, 2010, 1:44 pm

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by bolobb »

ithinc wrote:Version 1.0pre6 is released.

Ctrl+Shift+Z: Open/Close Recently Closed Tabs


CtrlShftZ worked, then I changed the shortcut with keyconfig and now it doesn't work, it "views" but it doesn't "unviews".
ithinc
Posts: 1029
Joined: February 19th, 2008, 12:10 am

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by ithinc »

bolobb wrote:CtrlShftZ worked, then I changed the shortcut with keyconfig and now it doesn't work, it "views" but it doesn't "unviews".

Close popup needs special handling. Keyconfig may be not able to do it.
ithinc
Posts: 1029
Joined: February 19th, 2008, 12:10 am

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by ithinc »

ben_r_ wrote:Thats the thing. I am trying this extension on THREE computers, two brand new Macs and one PC. On the Macs, this is the ONLY extension running. Something is very odd here...

Could you attach a snapshot? Except this ONLY extension, do you have themes/user styles/etc.?
ithinc
Posts: 1029
Joined: February 19th, 2008, 12:10 am

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by ithinc »

DarkOne123 wrote:I've set New Tab to be my home page (which is Google.com) however when I click New Tab. In the address bar I still see "Search Bookmarks and history" this wasn't really a problem until the Google Instant Search came out which doesn't work when you click New Tab.

Set extensions.tabutils.markNewAsBlank to false.
bolobb
Posts: 94
Joined: April 25th, 2010, 1:44 pm

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by bolobb »

ithinc wrote:
bolobb wrote:CtrlShftZ worked, then I changed the shortcut with keyconfig and now it doesn't work, it "views" but it doesn't "unviews".

Close popup needs special handling. Keyconfig may be not able to do it.


Ok, so could you change the shortcut? For example CtrlShftQ, in order to avoid prblems in case of mistyping with Z.
bolobb
Posts: 94
Joined: April 25th, 2010, 1:44 pm

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by bolobb »

When in multirow tab mode, moving the arrow on the list of tabs highlights n tabs down, where n is the number of rows.
ithinc
Posts: 1029
Joined: February 19th, 2008, 12:10 am

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by ithinc »

bolobb wrote:Ok, so could you change the shortcut? For example CtrlShftQ, in order to avoid prblems in case of mistyping with Z.

Not likely. I can post a code snippet for you instead.

Code: Select all

    window.addEventListener("keypress", function(event) {
      if (event.ctrlKey && event.shiftKey && (event.charCode == 90 || event.charCode == 122)) {//Ctrl+Shift+Z
        let popup = document.getElementById('undoCloseTabPopup');
        if (popup.state == "open" || popup.state == "showing") {
          popup.hidePopup();
          event.preventDefault();
          event.stopPropagation();
        }
      }
    }, true);


bolobb wrote:When in multirow tab mode, moving the arrow on the list of tabs highlights n tabs down, where n is the number of rows.

This happens only when tabs on bottom. It roots in Firefox and no workaround now.
ithinc
Posts: 1029
Joined: February 19th, 2008, 12:10 am

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by ithinc »

braveheartleo wrote:
ithinc wrote:In fact, what you're describing is an intentional design. Auto-locked pinned tabs are not marked as locked, but behave like locked tabs. There are two points here:
1/ whether an auto-locked pinned tab should be styled as a locked tab,
2/ whether an auto-locked pinned tab could be unlocked.
If you treat "auto-locked" as a feature of pinned tabs, just like "auto-faviconized", these won't be a problem. Post your further requests to http://tabutils.uservoice.com for better tracking.

Going by my suggestion if you think it wise to implement, then we should treat the auto functions of pinned tabs with consistency with respect to manually protecting or locking the other tab modes. Then it also follows that the auto functions would now show proper active or inactive status for Lock or Protect tab menu items, and allow for deactivating any of the auto-functions for the current pinned tab, but leave it enabled for future pinned tabs.

We have pinned tabs always favionized. Do you think "Faviconize Tab" should also be checked and allows deactivating?

Going by your suggestion, there will be two more questions:
3/ What if a pinned tab is unpinned? Should auto-protected/locked state be deactivated?
4/ What if a pinned tab is restored? Should auto-protected/locked state be activated, despite of manually protected/locked state?
Post feature requests to http://tabutils.uservoice.com.
Post bug reports to https://github.com/ithinc/tabutils/issues.
User avatar
braveheartleo
Posts: 43
Joined: September 22nd, 2007, 3:27 am

Found one pair of competing options, out of a possible MANY

Post by braveheartleo »

I have found one pair of competing program options that causes unintended behavior.

If a tab is pinned and extensions.tabutils.autoPin is set to true, as it is the default, then a pinned tab that is neither locked nor protected (and neither auto-locked nor auto-protected for that matter) does not close when instructed to do so, but instead changes focus to another tab, but the pinned tab remains opened.

This is just one primary example of how unexpected behaviors occur for a program that offers a multitude of options. In my opinion, before other things get out of hand, perhaps it may be prudent to re-evaluate some of the options and simplify to avoid complexity.

I looked at the many TU prefs found in about:config, and noticed a number of extensions.tabutils.autoXXX prefs. I'm guessing that the purpose of those autoXXX prefs might be for child tabs to inherit whatever XXX property of the parent tab is set to. In the case above, pinning a tab and having autoPin set to true _prevents_ the pinned tab from closing, even though a protect function is provided to handle this behavior.

If there is good reason to have those autoXXX prefs set to true by default, or if they even need to exist for that matter, then perhaps those can be removed. Supporting tab state inheritance for users who like the idea may be good thing, but it never hurts to look at some existing solutions provided by other browsers as well. Having them as a guiding principle is better since considerable research has been put into designing their function and behavior.

Of course if those prefs _really_ need to exist, then perhaps you can re-evaluate by creating a table of behavior matrix to see how each of the prefs and functions in the add-on affect each other whenever activated or deactivated. I think all add-on options must go in harmony with each other, and prevent misbehavior where applicable. And from there put checks on prefs that may overlap or compete against another, thereby potentially increasing complexity of coding, and consequently troubleshooting and debugging.

I am offering my opinion to be constructive. I find that there is great motivation behind the add-on, and support the work behind it.
ithinc
Posts: 1029
Joined: February 19th, 2008, 12:10 am

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by ithinc »

braveheartleo wrote:Since we might be looking at revamping the presentation of this section in the appearance options, let me offer my full treatment of the details:

I think I would drop all current implementation and go for a minimalistic and consistent approach throughout the different tab modes (Pinned, Faviconized, or Normal tab) when dealing with Lock and Protect tab functions. If it is possible, I would place small dot icons at the top right corner of the tab, positioning it on the tab's top edge border and flushed right to the corner. Each dot would depict a color, like blue for Protected or red for Locked. I'm not much of a designer so it may be up to you, but I would go for whole-colored dot icons.
...
In this way, the implementation for Protected and Locked status icons is uniform across all tab modes, unlike the current implementation in which pinned tabs, faviconized tabs, and normal tabs have varying and disconnected behaviors for displaying status of the aforementioned.

Thanks for the helpful thoughts. It still depends on how auto-protected/locked pinned tabs should behave and appear. And I'm not good at making icons. Even the status bar buttons are still lack of proper icons.
Post feature requests to http://tabutils.uservoice.com.
Post bug reports to https://github.com/ithinc/tabutils/issues.
ithinc
Posts: 1029
Joined: February 19th, 2008, 12:10 am

Re: Found one pair of competing options, out of a possible M

Post by ithinc »

braveheartleo wrote:I have found one pair of competing program options that causes unintended behavior.

If a tab is pinned and extensions.tabutils.autoPin is set to true, as it is the default, then a pinned tab that is neither locked nor protected (and neither auto-locked nor auto-protected for that matter) does not close when instructed to do so, but instead changes focus to another tab, but the pinned tab remains opened.

This is just one primary example of how unexpected behaviors occur for a program that offers a multitude of options. In my opinion, before other things get out of hand, perhaps it may be prudent to re-evaluate some of the options and simplify to avoid complexity.

I looked at the many TU prefs found in about:config, and noticed a number of extensions.tabutils.autoXXX prefs. I'm guessing that the purpose of those autoXXX prefs might be for child tabs to inherit whatever XXX property of the parent tab is set to. In the case above, pinning a tab and having autoPin set to true _prevents_ the pinned tab from closing, even though a protect function is provided to handle this behavior.

No, you understand it wrong. autoPin means if the url is opened for the 2nd time, it will be automatically pinned, not related to non-closeable. What you refer to as an unclosed pinned tab is a bookmark instead. I may clear the auto-pin list which is stored in bookmarks, when extensions.tabutils.autoPin is set to false. Currently it is not done for I fear that some people may play with these options without enough knowledge.

braveheartleo wrote:If there is good reason to have those autoXXX prefs set to true by default, or if they even need to exist for that matter, then perhaps those can be removed. Supporting tab state inheritance for users who like the idea may be good thing, but it never hurts to look at some existing solutions provided by other browsers as well. Having them as a guiding principle is better since considerable research has been put into designing their function and behavior.

Of course if those prefs _really_ need to exist, then perhaps you can re-evaluate by creating a table of behavior matrix to see how each of the prefs and functions in the add-on affect each other whenever activated or deactivated. I think all add-on options must go in harmony with each other, and prevent misbehavior where applicable. And from there put checks on prefs that may overlap or compete against another, thereby potentially increasing complexity of coding, and consequently troubleshooting and debugging.

These autoXXX prefs are added very lately as a request from some people. I dislike them for I like simplicity too. I added them for these won't add much coding and so harmless. Let me know if you think some options are redundant. Post in Keep Tab Utilities light-weight.
Post feature requests to http://tabutils.uservoice.com.
Post bug reports to https://github.com/ithinc/tabutils/issues.
User avatar
braveheartleo
Posts: 43
Joined: September 22nd, 2007, 3:27 am

Re: [Ext] Tab Utilities 0.9.9.9 - light but featureful

Post by braveheartleo »

ithinc wrote:We have pinned tabs always favionized. Do you think "Faviconize Tab" should also be checked and allows deactivating?

Going by your suggestion, there will be two more questions:
3/ What if a pinned tab is unpinned? Should auto-protected/locked state be deactivated?
4/ What if a pinned tab is restored? Should auto-protected/locked state be activated, despite of manually protected/locked state?

I see.

Of course what I'll be offering now is based on Firefox 3.6.12, as it doesn't have a Pin tab function natively, unlike Firefox 4 that has it. So I will leave browser specific implementation to you.

In my opinion, if the difference between a Pinned tab and Faviconized tab is just tab arrangements (Pinned tabs are automatically put to the leftmost part of the tab bar and cannot be dragged for other arrangement, while Faviconized tab allows for arrangement anywhere on the tab bar, except to the Pinned tabs group), then perhaps we can simplify both functions as Pin tab, and make an exception via an option to allow tab arrangement with normal tabs for Pinned tabs.

If you would recall that even before browsers had a Pinned tab function natively, add-ons provided a way to _only_ display tab icons, but the tabs still behave like normal tabs and stay in place, and that they can be dragged around for arrangement. Now that Pinned tabs are native to some browsers, including the upcoming Firefox 4, and by approriately calling it as such, it is pinned in a group in the tab bar, separating it from normal tabs for management, then add-ons that faviconize tabs are no longer needed. I will follow suit with how browsers implement Pinned tabs function, but for users that request the ability to arrange Pinned tabs with normal tabs on the tab bar, then it's up to you if you will make an exception, but there must be sensible reason to and good research put on why current and upcoming browsers do not support this behavior.

I did notice, however that the Pinned tabs couldn't be arranged in their group. I'm not sure if this is a technical limitation for TU in Firefox 3, but if not, then at least make it so that Pinned tabs may be arranged in their group. The option for allowing Pinned tabs to be arranged with normal tabs just like Faviconized tabs, whether implemented or not, should have no bearing on the ability to arrange Pinned tabs.

Do you think "Faviconize Tab" should also be checked and allows deactivating?

I think by now this and all other related to this function has been answered, and we have achieved simplification and uniformity in handling tabs that are displayed by their icons.

p.s.
My reply to questions 3/ and 4/ will come shortly, as I don't want to be making the post too long. :-)
Last edited by braveheartleo on December 8th, 2010, 9:04 pm, edited 2 times in total.
Post Reply