Closed Bug 528723 Opened 15 years ago Closed 15 years ago

after opening a link from Library/History/Yesterday, the display changes to Today and sort changes to Visit Date

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3.7a2

People

(Reporter: eyalgruss, Unassigned)

References

Details

After opening a link from Library/History/Yesterday (or any other folder), the display changes to Today. This is very annoying when i am trying to open several consecutive links from yesterday.
in addition also the sort changes to sort by Visit Date
Summary: after opening a link from Library/History/Yesterday, the display changes to Today → after opening a link from Library/History/Yesterday, the display changes to Today and sort changes to Visit Date
It is annoying, so -- can this be fixed in 3.7? How can we help?
blocking2.0: --- → ?
I can not reproduce the issue any more after the following build. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100226 Minefield/3.7a2pre ID:20100226035959
(In reply to comment #3) > I can not reproduce the issue any more after the following build. > Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100226 > Minefield/3.7a2pre ID:20100226035959 is this the build where we landed lazy treeviews (bug 520659)? That bug changed a LOT of code, and possibly fixed some bug. i can't reproduce too. let's call it fixed.
Status: NEW → RESOLVED
Closed: 15 years ago
Depends on: 520659
Resolution: --- → FIXED
blocking2.0: ? → ---
Still happens in the most recent stable FireFox (3.6.3) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729) But if it's fixed in alpha that's good.
This is still not fixed in 3.6.3.
it does not matter, bugs are fixed once they are fixed in current development version, that will become a future stable version. This bug will be fixed in FX4.0.
Thanks for the info. At least I know how long I will have to wait for a fix.
"... it does not matter it does not matter, bugs are fixed once they are fixed in current development version" That's true only if you think users don't count. For use bugs are fixed when they are no longer in our running code. Is the FX4.0 comment an official statement that it's not going to fixed in version 3?
It's not going to be fixed in 3.x. This is not done because users don't count, it's exactly the opposite, stable versions have pretty strict rules for allowed fixes because we want to minimize possibility introduce bugs or regressions to millions of users. Thus only important stability and security fixes are allowed.
I can live with this bug until 4.0 hits the web. What I cannot live with are big UI changes which cannot be reverted to the old default (happened with AwesomeBar searching through bookmarks, took a while to get done properly), or functionality which is on by default (geo.enabled being an example) which has no checkbox in the UI, which affects privacy and whose name and location are obscure enough that majority of people won't find it, much less understand what it does. I sincerely hope there will be no more such gimmicks in future versions of Firefox.
Why is this marked fixed?
because it has been fixed by bug 520659.
(In reply to comment #15) > because it has been fixed by bug 520659. Bear in mind though that it is not fixed for users, only for developers. Marking it as fixed before it is fixed in released code only confuses people. In my opinion, it should be TARGETED TO BE FIXED, along with a version in which end users will be able to receive fix.
(In reply to comment #16) > (In reply to comment #15) > > because it has been fixed by bug 520659. > In my opinion, it should be TARGETED TO BE FIXED, along with a version in which > end users will be able to receive fix. This is how things work by our rules, when the bug is fixed on mozilla-central it is marked as fixed. Target milestone indicates the first version where the fix will be available (I've just set it here since it was unset).
Target Milestone: --- → Firefox 3.7a2
I absolutely agree with Igor Levicki's comment. The bug hasn't been fixed until a fix is available. Calling this problem "fixed" is misleading to users (and could prompt us to rereport it as a new bug). Yes, you need some internal status to indicate the problem, but it shouldn't be stated as "fixed". Alternately, let us download the fix. Second alternative: let us have the old plug-in that worked.
This is not the place to discuss Mozilla rules for bugs and patches, since they are valid for all bugs, please move the discussion to a Mozilla newgroup like mozilla.dev.apps.firefox.
Verified on: Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.2a1pre) Gecko/20110403 Firefox/4.2a1pre
Status: RESOLVED → VERIFIED
As far as I can see, this bug is the same or similar to Bug 651906 for Firefox 3.6.x on Linux platforms, and as for now, it seems to be still _effectively_ unfixed (not just formally fixed as described above) even with Firefox 6.0. In my case, it came up when I updated from FF 3.5.19 to 3.6.20, so by now I returned to 3.5.19 where this bug didn't show up yet. Although permanently reminded of the necessity to update my browser now, I don't know whether it's worth to install these extra 5 MB of memory consumed by current FF, if things go that way...
You need to log in before you can comment on or make changes to this bug.