Open Bug 1472989 Opened Last year Updated 5 months ago
Rename/rewire tab attribute notselectedsinceload because its name and it not being removed immediately on tab selection is confusing
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Build ID: 20180621125625 Steps to reproduce: Open new tab with middle click. Select it. Actual results: Value of notselectedsinceload tab`s attribute is true Expected results: Value of notselectedsinceload tab`s attribute is false
Has STR: --- → yes
Component: Untriaged → Tabbed Browser
OS: Unspecified → All
Hardware: Unspecified → All
Jaws, what's the expected behavior here?
(In reply to Dão Gottwald [::dao] from comment #1) > Jaws, what's the expected behavior here? Jaws is out, so attempting to reply here given I reviewed the changes... Tabs should only show a blue burst if they have been selected between the start of the toplevel load and when that load finishes. So I'm pretty sure the current behavior is as expected... comment #0 is not very clear - does the tab load before or after it is selected? Even if this happened before (so no blue burst, and the attribute gets set), once the tab starts loading a second time, assuming it has been selected before then and was not deselected before the next load started, the attribute gets removed, from my reading of the code. This is also what I see when I follow these steps: 1. middle/command-click the 'description' link in this bug to load it in a background tab 2. wait for it to load (attribute is set on that new unselected tab) 4. select tab (attribute is still set) 5. hit refresh and wait for the new load (attribute gets removed) That seems OK to me? Maybe I'm misunderstanding the problem comment #0 is trying to raise?
I think you understand it correctly. But if it is ok, what does mean this attribute after all? In your`s scenario - isnt the tab selected after load (in step 4)? It is. Refreshing page removes attribute (btw, not sets false which can be confusing and non consequent), but consider that the tab is already selected. So steps to reproduce would be: 1. middle/command-click the 'description' link in this bug to load it in a background tab 2. wait for it to load 3. select tab Actual result is: Value of notselectedsinceload tab`s attribute is true Expected results: Value of notselectedsinceload tab`s attribute is false (or attribute removed) Also in this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1453957#c14 Gingerbread Man suggested that this attribute can be replacement for removed unread attribute, but at the moment it cannot.
So implementation-wise, for what we use this attribute for in Firefox core, there's no need to remove the attribute immediately. I see 2 choices: - add code to remove the attribute immediately once a tab is selected. That would remove the confusion, though it might add confusion because it's not strictly necessary for the purpose for which the attribute is used. - rename the attribute to reduce confusion. I don't have any good ideas for a new name. Maybe "lastloadhappenedinbackground" or something, though that's even longer than the already-long current name.
Summary: tab attribute notselectedsinceload is never switch to false → Rename/rewire tab attribute notselectedsinceload because its name and it not being removed immediately on tab selection is confusing
You need to log in before you can comment on or make changes to this bug.