Closed Bug 652379 Opened 13 years ago Closed 13 years ago

place:folder=-1 returns a non-empty result

Categories

(Toolkit :: Places, defect)

Product:
Toolkit
Component:
Places
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla6

People

(Reporter: tabutils+bugzilla, Assigned: mak)

References

Details

(Keywords: regression, Whiteboard: [places-next-wanted][fixed-in-places])

Attachments

(1 file)

patch v1.0
10.63 KB, patch
dietrich
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110423 Firefox/6.0a1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110423 Firefox/6.0a1

From the latest nightly build, "place:folder=-1" query returns non-empty result, is it intended?


Reproducible: Always
what does it contain?
Component: Bookmarks & History → Places
Product: Firefox → Toolkit
QA Contact: bookmarks → places
I suppose a regression from bug 641074, we should return a valid result, but empty.
Blocks: 641074
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
The result seems the History items. I'm not sure. You may create a bookmark for "place:folder=-1" to have a test.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Whiteboard: [places-next-wanted]
Summary: Why "place:folder=-1" query returns non-empty result? → place:folder=-1 returns a non-empty result
Attached patch patch v1.0 — — Splinter Review 

        Attachment #528773 -
        Flags: review?(dietrich)

    
  
Flags: in-testsuite?

    
    

    
  
Note that although "place:folder=-1" returns non-empty result, "place:folder=-2" works as expected. Strange!

    
    

    
  
I know, -1 is a special value we use for "not-bookmarked", and that's why it works differently. The above patch should fix that and also make it faster.

    
    

    
  
Comment on attachment 528773 [details] [diff] [review]
patch v1.0

Patch looks fine. Is the warning really necessary?

        Attachment #528773 -
        Flags: review?(dietrich) → review+

    
    

    
  
(In reply to comment #7)
> Comment on attachment 528773 [details] [diff] [review]
> patch v1.0
> 
> Patch looks fine. Is the warning really necessary?

I want to be sure that we don't hit this path in tests (unless wanted), otherwise the written test would be garbage.

    
    

    
  
http://hg.mozilla.org/projects/places/rev/e7c50e928098
Whiteboard: [places-next-wanted] → [places-next-wanted][fixed-in-places]

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/e7c50e928098
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla6

    
    

    
  
Verified with Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110430 Firefox/6.0a1.

But what does "place:folder=FOOBAR" mean? It returns the same result as "place:folder=-1" did.
Status: RESOLVED → VERIFIED

    
    

    
  
(In reply to comment #11)
> But what does "place:folder=FOOBAR" mean? 

In this case, the query doesn't parse because FOOBAR means nothing, so a generic history query is created, that's by design (even if surprising).

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: