If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Scrolling tab bar with "Remember password?" dialog active makes dialog move outside of window.

RESOLVED INVALID

Status

()

Firefox
Tabbed Browser
RESOLVED INVALID
3 months ago
21 days ago

People

(Reporter: R030t1, Unassigned)

Tracking

53 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170518000419

Steps to reproduce:

Scroll the tab bar after entering a password and doing nothing with the dialog that asks whether or not the password should be remembered.


Actual results:

The dialog moved far outside the active window's borders.


Expected results:

Dialog should be clamped to window extents, preferably within the menu elements surrounding the tabs.

Unfortunately, this is hard to take a picture of.

Updated

3 months ago
Component: Untriaged → Tabbed Browser

Comment 1

3 months ago
I can't reproduce this. Can you reproduce this in a clean profile? Can you provide more details about which site this happens with? For me, the "Do you want to remember this password" prompt shows up pointing towards the identity block (the bit with a lock icon and/or (i) icon to the left of the URL in the URL bar), not to the tab strip, so I also don't see why it would move at all when scrolling the tabstrip. Are you using an add-on of some sort that hides or modifies the URL bar, maybe?
Flags: needinfo?(R030t1)
(Reporter)

Comment 2

3 months ago
This happens with every website. I am using Vimperator with "gui=none,tabs" which may the cause. Do you know how to tell if the behavior of attaching the dialog to the tab is associated with the addon? If so I will inquire with the addon's author, my apologies.
Flags: needinfo?(R030t1)
(Reporter)

Updated

3 months ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → INVALID

Comment 3

3 months ago
(In reply to R030t1 from comment #2)
> This happens with every website. I am using Vimperator with "gui=none,tabs"
> which may the cause. Do you know how to tell if the behavior of attaching
> the dialog to the tab is associated with the addon? If so I will inquire
> with the addon's author, my apologies.

Yeah, this will be happening with the add-on because we use the tab as a fallback if the URL bar is not available. Maybe Johann can clarify why we even do that, and if whatever case that's catering for (I suspect chromeless popup windows) is also something where there are tabs (there aren't any in chromeless popup windows).
Flags: needinfo?(jhofmann)
(Reporter)

Comment 4

3 months ago
Well, if the fallback behavior is Firefox's then maybe the bug should remain open. All Vimperator does is create a situation where the bug surfaces.

On past versions at least Ctrl+Click can open tabs in a chromeless window. At one point I think it was possible to drag tabs to a popup window but that may no longer be the case.

Comment 5

3 months ago
(In reply to R030t1 from comment #4)
> On past versions at least Ctrl+Click can open tabs in a chromeless window.
> At one point I think it was possible to drag tabs to a popup window but that
> may no longer be the case.

Neither of these work for me for windows opened without a 'real' navigation toolbar.
(In reply to :Gijs from comment #3)
> (In reply to R030t1 from comment #2)
> > This happens with every website. I am using Vimperator with "gui=none,tabs"
> > which may the cause. Do you know how to tell if the behavior of attaching
> > the dialog to the tab is associated with the addon? If so I will inquire
> > with the addon's author, my apologies.
> 
> Yeah, this will be happening with the add-on because we use the tab as a
> fallback if the URL bar is not available. Maybe Johann can clarify why we
> even do that, and if whatever case that's catering for (I suspect chromeless
> popup windows) is also something where there are tabs (there aren't any in
> chromeless popup windows).

Yeah, there were some edge cases that we didn't end up handling super cleanly in popup notifications since introducing the followanchor attribute. I'd like to get back to that code, but I'm not sure it's worth the effort since the existing solution covers the 99% of use cases. IIRC most problems revolved around DOM fullscreen, where the identity icon can not be attached to the identity block (bug 1355000) and around re-creating elements in the identity block e.g. when switching tabs (bug 1340538). I think it's unrelated to chromeless popups. Doing this is definitely necessary right now, but I suspect with more effort one could find a more elegant solution that allows us to attach to the correct anchor once it appears. I've been trying to find the time ever since we shipped 53. I think we can leave this closed, there are enough bugs about this and this one is clearly only about add-on compat.
Flags: needinfo?(jhofmann)
(Reporter)

Comment 7

3 months ago
(In reply to Johann Hofmann [:johannh] from comment #6)
> (In reply to :Gijs from comment #3)
> > (In reply to R030t1 from comment #2)
> > > This happens with every website. I am using Vimperator with "gui=none,tabs"
> > > which may the cause. Do you know how to tell if the behavior of attaching
> > > the dialog to the tab is associated with the addon? If so I will inquire
> > > with the addon's author, my apologies.
> > 
> > Yeah, this will be happening with the add-on because we use the tab as a
> > fallback if the URL bar is not available. Maybe Johann can clarify why we
> > even do that, and if whatever case that's catering for (I suspect chromeless
> > popup windows) is also something where there are tabs (there aren't any in
> > chromeless popup windows).
> 
> Yeah, there were some edge cases that we didn't end up handling super
> cleanly in popup notifications since introducing the followanchor attribute.
> I'd like to get back to that code, but I'm not sure it's worth the effort
> since the existing solution covers the 99% of use cases. IIRC most problems
> revolved around DOM fullscreen, where the identity icon can not be attached
> to the identity block (bug 1355000) and around re-creating elements in the
> identity block e.g. when switching tabs (bug 1340538). I think it's
> unrelated to chromeless popups. Doing this is definitely necessary right
> now, but I suspect with more effort one could find a more elegant solution
> that allows us to attach to the correct anchor once it appears. I've been
> trying to find the time ever since we shipped 53. I think we can leave this
> closed, there are enough bugs about this and this one is clearly only about
> add-on compat.

I'm slightly confused that you recognize this as being caused by code in Firefox and part of a legitimate issue but still want to leave this closed. On most trackers I'm a part of bugs will be kept open unless it is extremely obvious the reporter is beyond clueless or just annoying the developers. On the Mozilla tracker any excuse at all is used to close something, the most egregious examples of which are bugs closed simply because the contributor who immediately follows up on it can't reproduce it (despite the bug author having lots of description or generally sounding competent) - most trackers I'm on would leave it open for a few months so other developers could look at it. Presumably what was reported was a valid issue and hard to reproduce; if it wasn't, it would have been caught and fixed before the release was made.

Other comments aside I'm going to mark this as verified. If you want me to edit the title please say so; if editing seems inappropriate I can resubmit the issue with a more concise outline.

Like I mentioned in my other reply asking the plugin author doesn't seem appropriate if the problem is in the default behavior of Firefox, even if the plugin is what is causing the edge case. It might be possible the plugin author will contribute code if they have the time, but I think the issue needs to be left open here.
Status: RESOLVED → VERIFIED

Comment 8

3 months ago
(In reply to R030t1 from comment #7)
> (In reply to Johann Hofmann [:johannh] from comment #6)
> > (In reply to :Gijs from comment #3)
> > > (In reply to R030t1 from comment #2)
> > > > This happens with every website. I am using Vimperator with "gui=none,tabs"
> > > > which may the cause. Do you know how to tell if the behavior of attaching
> > > > the dialog to the tab is associated with the addon? If so I will inquire
> > > > with the addon's author, my apologies.
> > > 
> > > Yeah, this will be happening with the add-on because we use the tab as a
> > > fallback if the URL bar is not available. Maybe Johann can clarify why we
> > > even do that, and if whatever case that's catering for (I suspect chromeless
> > > popup windows) is also something where there are tabs (there aren't any in
> > > chromeless popup windows).
> > 
> > Yeah, there were some edge cases that we didn't end up handling super
> > cleanly in popup notifications since introducing the followanchor attribute.
> > I'd like to get back to that code, but I'm not sure it's worth the effort
> > since the existing solution covers the 99% of use cases. IIRC most problems
> > revolved around DOM fullscreen, where the identity icon can not be attached
> > to the identity block (bug 1355000) and around re-creating elements in the
> > identity block e.g. when switching tabs (bug 1340538). I think it's
> > unrelated to chromeless popups. Doing this is definitely necessary right
> > now, but I suspect with more effort one could find a more elegant solution
> > that allows us to attach to the correct anchor once it appears. I've been
> > trying to find the time ever since we shipped 53. I think we can leave this
> > closed, there are enough bugs about this and this one is clearly only about
> > add-on compat.
> 
> I'm slightly confused that you recognize this as being caused by code in
> Firefox and part of a legitimate issue but still want to leave this closed.

I can't speak for Johann, but I think his comment suggests that the issue will be taken care of by bug 1355000. It doesn't seem useful to have 2 reports open for this. Perhaps marking it as a duplicate would make more sense.

> On most trackers I'm a part of bugs will be kept open unless it is extremely
> obvious the reporter is beyond clueless or just annoying the developers.

Leaving non-actionable reports open makes it hard to find the ones that *are* actionable or clearly bugs. 

> On
> the Mozilla tracker any excuse at all is used to close something,

Closing isn't deleting. It's a non-destructive action. If closing a bug is wrong, we can reopen it. As a result, I don't think "excuse" is the correct word here. We're not looking to close as many bugs as possible as invalid/worksforme, and as such don't "need" an "excuse" to close one. We *are* looking to make sure that components contain topical, actionable and correctly-prioritized bugs. Given the volume of bug reports we receive, this is crucial to maintaining a useful bug tracker.

> the most
> egregious examples of which are bugs closed simply because the contributor
> who immediately follows up on it can't reproduce it (despite the bug author
> having lots of description or generally sounding competent)

I haven't seen this, and going back in your bugzilla history over the last 3 months I can't see examples of this, either. Hard to respond to this criticism without concrete examples - but please email a mailing list (or, if you prefer, me privately) with any such bugs, as this (otherwise presumably unrelated) bug isn't really the best place to continue this conversation.

> - most trackers
> I'm on would leave it open for a few months so other developers could look
> at it. Presumably what was reported was a valid issue and hard to reproduce;
> if it wasn't, it would have been caught and fixed before the release was
> made.

We do not fix all bugs we're aware of before a release, and because of the architecture of add-ons right now, and the multitude of hidden preferences (never mind external software/hardware/OS factors), it is not at all certain that a bug is reproducible, or actually a Firefox issue *only* because someone reported it.

> Like I mentioned in my other reply asking the plugin author doesn't seem
> appropriate if the problem is in the default behavior of Firefox, even if
> the plugin is what is causing the edge case. It might be possible the plugin
> author will contribute code if they have the time, but I think the issue
> needs to be left open here.

I think this is fair, but I don't think there's anything much to be done here besides bug 1355000, so not convinced it's useful to keep this bug open in addition to that one.
Yup, fixing bug 1355000 would likely solve this issue as well. Even if it would not, the problem you're describing is caused by an add-on breaking primary UI, which is not supported (and as such INVALID or WONTFIX seems fitting to me). If you find cases of this happening on a clean profile (such as bug 1355000) we should definitely track it in a bug.

> Other comments aside I'm going to mark this as verified. If you want me to edit the title please say so; if editing seems inappropriate I can resubmit the issue with a more concise outline.

Hm, I don't see how this is VERIFIED (as in, a QA person verified that the problem was fixed).
Status: VERIFIED → RESOLVED
Last Resolved: 3 months ago3 months ago

Comment 10

3 months ago
(In reply to Johann Hofmann [:johannh] from comment #9)
> > Other comments aside I'm going to mark this as verified. If you want me to edit the title please say so; if editing seems inappropriate I can resubmit the issue with a more concise outline.
> 
> Hm, I don't see how this is VERIFIED (as in, a QA person verified that the
> problem was fixed).

'verified' in general means someone other than the person who caused the bug to be marked resolved (whether fixed, duplicate, wontfix, whatever) has checked that the resolution is accurate. It has consequences other than QE-related ones (notably that reopening 'verified' dupe/wontfix bugs if you have no privileges on the bugzilla instance is impossible, which we sadly sometimes have to use if we end up in a close/reopen 'war' with someone on a bug).
(Reporter)

Comment 11

21 days ago
(In reply to :Gijs (queue backed up, slow) from comment #8)
> (In reply to R030t1 from comment #7)
> > (In reply to Johann Hofmann [:johannh] from comment #6)
> > > (In reply to :Gijs from comment #3)
> > > > (In reply to R030t1 from comment #2)
> > > > > This happens with every website. I am using Vimperator with "gui=none,tabs"
> > > > > which may the cause. Do you know how to tell if the behavior of attaching
> > > > > the dialog to the tab is associated with the addon? If so I will inquire
> > > > > with the addon's author, my apologies.
> > > > 
> > > > Yeah, this will be happening with the add-on because we use the tab as a
> > > > fallback if the URL bar is not available. Maybe Johann can clarify why we
> > > > even do that, and if whatever case that's catering for (I suspect chromeless
> > > > popup windows) is also something where there are tabs (there aren't any in
> > > > chromeless popup windows).
> > > 
> > > Yeah, there were some edge cases that we didn't end up handling super
> > > cleanly in popup notifications since introducing the followanchor attribute.
> > > I'd like to get back to that code, but I'm not sure it's worth the effort
> > > since the existing solution covers the 99% of use cases. IIRC most problems
> > > revolved around DOM fullscreen, where the identity icon can not be attached
> > > to the identity block (bug 1355000) and around re-creating elements in the
> > > identity block e.g. when switching tabs (bug 1340538). I think it's
> > > unrelated to chromeless popups. Doing this is definitely necessary right
> > > now, but I suspect with more effort one could find a more elegant solution
> > > that allows us to attach to the correct anchor once it appears. I've been
> > > trying to find the time ever since we shipped 53. I think we can leave this
> > > closed, there are enough bugs about this and this one is clearly only about
> > > add-on compat.
> > 
> > I'm slightly confused that you recognize this as being caused by code in
> > Firefox and part of a legitimate issue but still want to leave this closed.
> 
> I can't speak for Johann, but I think his comment suggests that the issue
> will be taken care of by bug 1355000. It doesn't seem useful to have 2
> reports open for this. Perhaps marking it as a duplicate would make more
> sense.
> 

Thank you. I did not know about that bug, I am content to have that be open in this bug's stead.

> > On most trackers I'm a part of bugs will be kept open unless it is extremely
> > obvious the reporter is beyond clueless or just annoying the developers.
> 
> Leaving non-actionable reports open makes it hard to find the ones that
> *are* actionable or clearly bugs. 
> 
> > On
> > the Mozilla tracker any excuse at all is used to close something,
> 
> Closing isn't deleting. It's a non-destructive action. If closing a bug is
> wrong, we can reopen it. As a result, I don't think "excuse" is the correct
> word here. We're not looking to close as many bugs as possible as
> invalid/worksforme, and as such don't "need" an "excuse" to close one. We
> *are* looking to make sure that components contain topical, actionable and
> correctly-prioritized bugs. Given the volume of bug reports we receive, this
> is crucial to maintaining a useful bug tracker.
> 

Okay, if you are saying that they are still referred to then I will refrain from posting again about the Mozilla bug handling policy. Unfortunately it seems to me that "open" is more likely to garner attention. I realize having any other policy might simply result in a situation where filtering by "open" inundates the user with too much information, but other projects I have seen seem to operate fine with trackers full of bugs. It just makes it more clear that the situation is truly hopeless :-)

> > the most
> > egregious examples of which are bugs closed simply because the contributor
> > who immediately follows up on it can't reproduce it (despite the bug author
> > having lots of description or generally sounding competent)
> 
> I haven't seen this, and going back in your bugzilla history over the last 3
> months I can't see examples of this, either. Hard to respond to this
> criticism without concrete examples - but please email a mailing list (or,
> if you prefer, me privately) with any such bugs, as this (otherwise
> presumably unrelated) bug isn't really the best place to continue this
> conversation.
> 

I understand. I do not mean to attack any particular developer, but if I did, I would stress that it would only be because I would like to hope they make the most useful contributions to Mozilla and Firefox that is possible (so it would more accurately be constructive criticism). I have learned to avoid making careful observations about such things, as when those observations are presented as part of a critique people tend to feel like they are being attacked. If you think it would be helpful to find such instances and refer them somewhere I will try to do that.

Based on my observations people want to be helpful. People who want to be helpful may attempt to handle bugs they do not know how to solve. As they don't know what to do to help, but still want to do something, seeking to invalidate the bug is an attractive option. Someone who is more experienced may eventually come across the bug, were it left open, and be able to realize what is happening behind the scenes despite not being able to personally reproduce it.

I see this elsewhere, but it seems like Firefox is particularly active. I invite you to look for it. My apologies if this is inappropriate for this report, but there is a fairly high barrier to posting it anywhere else.

> > - most trackers
> > I'm on would leave it open for a few months so other developers could look
> > at it. Presumably what was reported was a valid issue and hard to reproduce;
> > if it wasn't, it would have been caught and fixed before the release was
> > made.
> 
> We do not fix all bugs we're aware of before a release, and because of the
> architecture of add-ons right now, and the multitude of hidden preferences
> (never mind external software/hardware/OS factors), it is not at all certain
> that a bug is reproducible, or actually a Firefox issue *only* because
> someone reported it.
> 

From the user's perspective, if they encounter a bug while using Firefox it is an issue with Firefox. The root cause may end up being some inconsistency in Window's API, but the user doesn't know that, and it would take a developer to figure that out. Likewise hard to reproduce issues are likely valid, unless there is some way to conclude that the user is mistaken in what they have seen.

If the Firefox project has found through experience that it is best to treat these bugs in a certain way then I do not think I can criticize their solution without more understanding.


(In reply to Johann Hofmann [:johannh] - PTO until 09/04 from comment #9)
> Yup, fixing bug 1355000 would likely solve this issue as well. Even if it
> would not, the problem you're describing is caused by an add-on breaking
> primary UI, which is not supported (and as such INVALID or WONTFIX seems
> fitting to me). If you find cases of this happening on a clean profile (such
> as bug 1355000) we should definitely track it in a bug.
> 

The add-on breaks the primary UI by using API exposed by Firefox. If Mozilla does not want to support the API it has designed into Firefox that is fine, but it seems in that case that the API should be removed. I would appreciate it not being removed, as so much functionality has already been removed that various useful add-ons are hard to port to the newer APIs (which usually offer less features in some mistaken belief that this makes them more secure).

In addition, the fact this bug exists (to my understanding) is because the UI code's author realized some of the UI might not exist when the dialog is created. The situation Vimperator is creating has an attempt to handle it already in the code, but it doesn't happen to work perfectly. The inclusion of this code can be reconsidered, but you don't seem to be speaking to the merits of either option in your comment.

> > Other comments aside I'm going to mark this as verified. If you want me to edit the title please say so; if editing seems inappropriate I can resubmit the issue with a more concise outline.
> 
> Hm, I don't see how this is VERIFIED (as in, a QA person verified that the
> problem was fixed).

My apologies, I mistook VERIFIED for "VERIFIED bug."
You need to log in before you can comment on or make changes to this bug.