Closed Bug 303126 Opened 19 years ago Closed 15 years ago

Remove the <link> tags in the <head> for Saved Searches

Categories

(Bugzilla :: Bugzilla-General, enhancement)

Product:
Bugzilla
Component:
Bugzilla-General
Version:
2.20
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 4.0

People

(Reporter: cso, Assigned: Callek)

Details

Attachments

(1 file, 6 obsolete files)

ver1 -- Just remove the <head> links
733 bytes, patch
LpSolit
: review+
mkanat
: review+
Details | Diff | Splinter Review 
There is an option to exclude Saved Searches from appearing in the Footer, but
some people would like to exclude them from appearing in the <link> tags as well.

Two options were discussed in #mozwebtools - using linkinfooter or using a new
option, the forthcoming patch adds a new option
Attached patch Trunk Patch v1 (obsolete) — — Splinter Review 

  

  



        Attachment #191379 -
        Flags: review?
Severity: normal → enhancement
Target Milestone: --- → Bugzilla 2.22
OS: Linux → All
Hardware: PC → All

    
    

    
  
Comment on attachment 191379 [details] [diff] [review]
Trunk Patch v1

I'm concerned about the usability impact of this additional UI, especially
given that the vast majority of users don't use the link toolbar.  On the other
hand, there doesn't seem to be a way to sniff for its presence, and some users
have legitimate reasons to want to exclude links from the toolbar but not from
the footer, so perhaps this is the best solution.

Note that the link toolbar never really caught on, and support for it seems to
be dying across the web, so perhaps Bugzilla should follow suit and drop its
support for it.  In the meantime, however, it should work well for our users,
so barring some better solution this should go.

Overall the patch looks good, but unfortunately it's rotted, hence r-.

  

  



        Attachment #191379 -
        Flags: review? → review-

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v2 (obsolete)
        — 
          — Splinter Review
      

    


  
Patch v2 - Unbitrotted only.

  

  



        Attachment #191379 -
        Attachment is obsolete: true

        Attachment #195451 -
        Flags: review?(myk)

    
    

    
  
Comment on attachment 195451 [details] [diff] [review]
Patch v2

With this patch, the "My Bugs" link has only one checkbox whose cell spans both
the "Show in Footer" and "Show in Link Toolbar" columns, and existing searches
aren't shown in the link toolbar by default.  "My Bugs" should also be
settable, and existing searhes should be shown in the link toolbar by default
as they are without the patch.

  

  



        Attachment #195451 -
        Flags: review?(myk) → review-

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v3 (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #4)
> (From update of attachment 195451 [details] [diff] [review] [edit])
> With this patch, the "My Bugs" link has only one checkbox whose cell spans
both
> the "Show in Footer" and "Show in Link Toolbar" columns, and existing
searches
> aren't shown in the link toolbar by default.	"My Bugs" should also be
> settable, and existing searhes should be shown in the link toolbar by default

> as they are without the patch.

Hmm, current behavior is that hiding "My Bugs" hides it from both the <link>
tags AND the footer, hence they way the UI is designed. I've fixed the bit
about it being ticked by default though...

  

  



        Attachment #195451 -
        Attachment is obsolete: true

        Attachment #195457 -
        Flags: review?(myk)

    
    

    
  
Comment on attachment 195457 [details] [diff] [review]
Patch v3

This still doesn't enable links in the link toolbar for existing searches.

  

  



        Attachment #195457 -
        Flags: review?(myk) → review-

    
    

    
  
Well I just wanted to reply to c#4 (slightly off-topic of bug though);

The "link toolbar" support, I admit is a bit degraded across common UA's
(Firefox does not support it without an extension); however it is still present
in Suite/SeaMonkey (granted not shown by default, but operateable via prevalent
UI menu option).

The effects of exposing "important" links via <link /> in the head of a document
is not only useful for the Link toolbar but also assistive technology, (screen
readers, RSS Readers, etc.) Removing them from Bugzilla simply due to "Link
toolbar is almost phased out" seems to be a very dumbed down, and doomed
opinion.  I use it for the "assistive" technology aspect that Suite exposes,
makes the "important" links easily accessible for me, without having to search a
page. Next/Forward/Last/First links are especially useful.  Nevermind the "More"
section.

Everyone I know whom I have shown it to, (family who even do not know much at
all about computers) have found it especially easy to use, (same across
differing websites, etc.).  So for that reason alone, I would advocate keeping
it.  This bug itself was filed from my talking in #bmo with colin and justdave,
about how I wanted to turn off some of them, due to me having SOooo Many saved
queries due to the ability to whine (~200 or so saved); which with dialup,
severly slows down my bugzilla usage when I am logged in, which is very sub-optimal.

  

  



    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v4 (obsolete)
        — 
          — Splinter Review
      

    


  
This patch makes linkintoolbar be on by default for all Saved Searches,
regardless of whether linkinfooter is on to give the current behaviour by
default.

  

  



        Attachment #195457 -
        Attachment is obsolete: true

        Attachment #196661 -
        Flags: review?(myk)

    
    

    
  
Comment on attachment 196661 [details] [diff] [review]
Patch v4

Moving review to someone else in the hope it might get in before 2.22 feature freeze.

  

  



        Attachment #196661 -
        Flags: review?(myk) → review?(LpSolit)

    
    

    
  
Comment on attachment 196661 [details] [diff] [review]
Patch v4

bitrotten

  

  



        Attachment #196661 -
        Flags: review?(LpSolit) → review-

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v4.1 (obsolete)
        — 
          — Splinter Review
      

    


  
Patch v4 Unbitrotted...

  

  



        Attachment #196661 -
        Attachment is obsolete: true

        Attachment #201365 -
        Flags: review?(LpSolit)

    
    

    
  
Comment on attachment 201365 [details] [diff] [review]
Patch v4.1

bitrotten. Colin, this is a 2.24 thing, right?

  

  



        Attachment #201365 -
        Flags: review?(LpSolit) → review-

    
    

    
  
(In reply to comment #12)
> (From update of attachment 201365 [details] [diff] [review] [edit])
> bitrotten. Colin, this is a 2.24 thing, right?

Probably, although I wouldn't mind if it went in to 2.22...

  

  



    
    

    
  
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

  

  


Target Milestone: Bugzilla 2.22 → Bugzilla 2.24

    
    

    
  
This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

  

  


Target Milestone: Bugzilla 3.0 → Bugzilla 3.2

    
    

    
  
Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.

  

  


Target Milestone: Bugzilla 3.2 → ---

    
    

    
  
FWIW, here: linkintoolbar wouldn't be necessary, but I think there's no reason to make <link> tags if they don't have linkinfooter set.

  

  



    
    

    
  
Wouldn't it make sense to stop adding saved searches into <link>, unconditionally? If this only helps 1% of users or less (I have no idea how many people use them), it probably doesn't worth the page size increase (though it remains much smaller than the 300+ lines of code used by the keywords chooser for autocompletion, on bmo).

  

  



    
    

    
  


  
First version, just remove it.

  

  



        Attachment #201365 -
        Attachment is obsolete: true

        Attachment #422480 -
        Flags: review?

    
  

        Attachment #422480 -
        Flags: review? → review?(LpSolit)

    
    

    
  


  
This patch and ver1 are mutually exclusive.

Please r+ one and r- the other :-) (or tell me to do "option 3" which is add a third pref to the prefs page to allow toggling each search seperately).

For Version 2 if needed I will go in and change the [internal] naming of the option I test for, but would need a suggestion on naming.

  

  



        Attachment #422481 -
        Flags: review?(LpSolit)

    
    

    
  
Comment on attachment 422480 [details] [diff] [review]
ver1 -- Just remove the <head> links

Personally, I'm for this one. I looked into IE8, and I'm unable to enable the link toolbar; I couldn't find any pref for this. Same for Firefox. Both browsers together, we reach 90% of all users, and I'm not even sure about Chrome, Safari or Opera having this pref somewhere. So let's remove something which is unusable or hard to discover for most of us. r=LpSolit

I still want mkanat's r+ before removing it entirely.

  

  



        Attachment #422480 -
        Flags: review?(mkanat)

        Attachment #422480 -
        Flags: review?(LpSolit)

        Attachment #422480 -
        Flags: review+

    
  
Assignee: colin.ogilvie → bugspam.Callek
Status: NEW → ASSIGNED
Flags: approval?
Target Milestone: --- → Bugzilla 3.8

    
    

    
  
(In reply to comment #21)
> (From update of attachment 422480 [details] [diff] [review])
> Personally, I'm for this one. I looked into IE8, and I'm unable to enable the
> link toolbar; I couldn't find any pref for this. Same for Firefox. Both
> browsers together, we reach 90% of all users, and I'm not even sure about
> Chrome, Safari or Opera having this pref somewhere. So let's remove something
> which is unusable or hard to discover for most of us. r=LpSolit
> 
> I still want mkanat's r+ before removing it entirely.

Much smaller subset of users, but SeaMonkey has a link toolbar that works and can show these if you wanted to test a use-case WITH the toolbar. the toolbar *is* hidden by default though, so its even smaller than the number of "seamonkey users who use bugzilla" would even GET UI for this, nevermind use it.

  

  



    
    

    
  
Comment on attachment 422480 [details] [diff] [review]
ver1 -- Just remove the <head> links

I'm all for it.

  

  



        Attachment #422480 -
        Flags: review?(mkanat) → review+

    
  

        Attachment #422481 -
        Attachment is obsolete: true

        Attachment #422481 -
        Flags: review?(LpSolit)

    
  
Flags: approval? → approval+
Summary: Add option to exclude a Saved Search from appearing in the <link> tags → Remove the <link> tags in the <head> for Saved Searches

    
    

    
  
$ bzr commit --message="Remove the <link> tags in the <head> for Saved Searches
" --fixes=mozilla:303126
No handlers could be found for logger "bzr"
Committing to: bzr+ssh://Callek%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified template/en/default/global/site-navigation.html.tmpl
Committed revision 6957.

  

  


Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED

    
    

    
  
(In reply to comment #24)
> $ bzr commit --message="Remove the <link> tags in the <head> for Saved Searches
> " --fixes=mozilla:303126

Bah, you forgot the "r=LpSolit r=mkanat a=mkanat" part in your checkin message.

  

  



    
    

    
  
Also, we still like to start the commit messages with the bug ID, like "Bug 123456: ".

  

  



    
    

    
  
(In reply to comment #26)
> Also, we still like to start the commit messages with the bug ID, like "Bug
> 123456: ".

O ok; I misunderstood that when reading on the --fixes stuff with bzr. I'll do it right the next time, I swear :/

  

  



    
  
Keywords: relnote

    
    

    
  
Mmm, actually, I've decided against relnote'ing this--I don't think enough people knew about the <link> tags for it to matter.

  

  


Keywords: relnote

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: