570838 - Return no longer triggers "Close Page" button on phishing/malware blocked site overlay

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Accessibility, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

STR:

1) Open http://caminobrowser.org/documentation/security/test-phishing/ in background tab and a foreground tab (current tab, e.g., via link-click, to avoid bug 563321)
2) In the foreground (current tab), press Return

ER: Tab closes
AR: Nothing

3) Switch to the background tab
4) Press Return

ER: Tab closes
AR: Nothing

Both of these work in 2.0.x, whether the button is focused or not; hendy supplied JS code when we rewrote the page (bug 480207 comment 21), and smorgan fixed the link-click case in bug 522422.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Also, should we have used the hack in bug 522422 for other error pages, too? netError didn't have a default button, so I guess we never cared, but I noticed the discrepancy when I was checking what used isBlockedErrorOverlayShowing.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Adding alert("foo"); to that JS function shows that the function is seeing the return keypress, which I guess means that click(); is failing.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

One more thing; this worked in our 1.9.1 build, too.  I have no idea how we would find a regression range on this, though :(

Comment 4

[Stuart Morgan]

Hopefully users won't see this page often enough that this will be a significant issue, so we could push it, but I'll try to take a quick look and see if we can trigger it differently.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I found http://stackoverflow.com/q/809108 and http://stackoverflow.com/q/809611, but I couldn't get that solution to actually work, either.

Walking up the methods, I wonder if the problem is http://mxr.mozilla.org/camino/source/camino/src/browser/BrowserWrapper.mm#1031 ?  I can't check that right now, but it should be pretty simple to log when I have more time…

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Also see bug 439682 comment 8 and bug 439682 comment 9, about the isTrusted stuff.

I added an 'oncommand' attribute to the XUL button, pressed return, and the oncommand function fired, so 

1) outButton.click(); in |handleKeypress(anEvent)| is working to simulate the event, and
2) the xul:button is registering a button-press/being triggered.

So I think this does mean that I'll find the event failing at our GetEventTrusted check.  I'm not sure why that might have changed between 1.9.1 and 1.9.2, though. :(

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Nope, I'm wrong; with return, nothing is even getting to BrowserWrapper's |onXULCommand:|; my NSLog is never triggered for the return case (but is triggered for a real click).

So something is breaking in between the <xul:button> registering our fake click (when oncommand="alert('fake click!');" successfully fires) and BrowserWrapper's |onXULCommand:|; I guess the <xul:button> is either eating the event or never sending an event we can see (depending on how <xul:button> and the normal event flow work).