Closed Bug 1017595 Opened 10 years ago Closed 10 years ago

Links from external applications sometimes fail to open (especially when Firefox is hidden)

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla36
Iteration:
36.2
Tracking Flags:
Tracking Status
firefox32 --- wontfix
firefox33 --- wontfix
firefox34 --- verified
firefox35 --- verified
firefox36 --- verified

People

(Reporter: erik, Assigned: smichaud)

References

Details

(4 keywords, Whiteboard: [STR in comment #41])

Attachments

(2 files)

mozconfig
(deleted), text/plain
Details
Fix
(deleted), patch
spohl
: review+
lmandel
: approval-mozilla-aurora+
lmandel
: approval-mozilla-beta+
Details | Diff | Splinter Review 
Since about 10 nightlies ago (I'm on 5/28/2014 now), links followed in external applications have sometimes failed to open in Firefox. I haven't got a solid repro ironed out yet, but here's what happens about 1 out of 50 times:

1. Click a link in Mail.app, or execute a Google query from Butler.
2. Nothing happens.

I would expect a new window to open in Firefox, showing the target of the link. Bringing Firefox to the front and then trying again always works.

I'll add more as I figure it out. I'm probably unusual in that I have external links configured to open in new windows.
A revised step 2: Nightly comes to the front, but nothing further happens.
This error in the console might be relevant:

    Comparable link missing required property: frecency NewTabUtils.jsm:836
Also happening in Aurora, 32.0a2, 2014-06-19. Working through my add-ons to see if it's one of them.
I turned off all add-ons except AdBlock Plus, and it's still happening.
The frecency error is not relevant; I just had the bug happen and leave no errors in the console at all.
I HAVE A REPRO!

In Nightly 2014-06-27, on OS X...

1. Bring FF to the front.
2. Hide it.
3. Try to open Slashdot using my Butler shortcut, command-shift-option-S.

FF comes to the front but doesn't open Slashdot.

Oddly, this does *not* repro is reliably for other external links, like clicking one in Mail.app. Sometimes it repros; sometimes it doesn't.
It happens about 1/3 of the time when FF is hidden but never when FF is shown (even if it is in the background).
Btw, I confirmed several repros with 0 add-ons in the Nightly 2014-06-07 episode.
Can somebody take a few minutes and at least try to repro this? I'm about ready to switch browsers.

It's not just Butler. Links from Mail.app also fail to open several times out of 10.
Severity: normal → major
Just repro'd it on the release-channel Firefox (32.0.3 as of this writing), on a brand new profile. Clicking links from Mail.app fails to open a new window about 1 of 8 times when FF is hidden. It also fails to open a new tab, in the case where "Open new windows in a new tab instead" is checked.

Doing searches and opening other pages from shortcut apps like Butler fail in the same way.
I repro this on current beta. It appeared for the first time last week, I think. It happens frequently when clicking through links in email from Thunderbird.
This bug also happens, if you try to open a HTML file on your hard disk: FF 32 comes to focus but doesn't open a new tab and doesn't display the HTML file. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1069864
Laura, Erik: by "hidden", do you mean "minimized"? (reading comment #7)

(I can't reproduce against 33 beta; really not sure what the determining factor here is)
Severity: major → critical
Component: General → Tabbed Browser
Flags: needinfo?(laura)
Flags: needinfo?(erik)
Keywords: papercut, qawanted, steps-wanted, ux-consistency
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1069864
Summary: Links from external applications sometimes fail to open → Links from external applications sometimes fail to open when Firefox is hidden
Thanks for taking a look, Gijs!

I do mean hidden, as in command-H. The bug still exists as of at least 35 Nightly.
Flags: needinfo?(laura)
Flags: needinfo?(erik)
OK, so cmd-H does something else than just switching to a different application? That's... strange. The visual effects seem to be the same. Sigh @ OSX. :-\

Anyway, I can reproduce after hitting cmd-H and opening a link from Thunderbird.
Flags: qe-verify+
Flags: in-testsuite?
Flags: firefox-backlog+
Keywords: qawanted, steps-wanted → regression, regressionwindow-wanted, reproducible
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1069864 → 
Mike, you recently looked into this for e10s, do you have time to take a look?
Flags: needinfo?(mconley)
A quick debug session shows that what's happening here is that nsBrowserContentHandler's handle function (implemented for nsICommandLineHandler), is not getting called from Gecko in the bad case.

So this appears to be a deeper platform issue, and I suspect it involves some level of our OS X integration (unless anybody has been able to reproduce this on Windows or Linux).

Cc'ing some of our fine Mac-dev folk.
Flags: needinfo?(mconley)
It may take me a while to look into this, but a regression window would very helpful (if one exists).

Erik, is that something you could provide?
Flags: needinfo?(erik)
If you read above, you can also see that it happened a bit earlier, on Aurora, 32.0a2, built 2014-06-19. In my very first comment, I also make a softer estimate: that it was introduced some 10 days before the 5/28/2014 nightly.
Here are the commits between 5/15/2014 and 5/28/2014:

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=5%2F15%2F2014&enddate=5%2F28%2F2014

Nothing jumps out at me...
I was referring to a regression window similar to what can be obtained via mozregression[1], i.e. "works in one nightly and doesn't work in the next". This would allow us to clear the regressionwindow-wanted flag. I'm saying 'similar to' because mozregression may not work here, due to the use of external apps etc. to reproduce.

[1] http://mozilla.github.io/mozregression/
I'm a bit crunched with some quarterly goals here, but I'll take a swing after those land if nobody else has.
I'm looking, but I'm scared of false negatives (ie, try lots of times, can't reproduce, but is in reality already buggy) considering the intermittent nature of this issue.

I can repro at least back to 2014-05-13, and marked 2014-05-12 as good. Tentative pushlog is: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=20ca234fd62b&tochange=4b6d63b05a0a

bug 996848 would fit the bill...
I'm no Cocoa expert by any means, but a quick debug session makes it seem as if hitting Cmd-H puts the NSApplication in kind of a funny state... we no longer seem to receive events from OS X for opening links (the stuff at [MacApplicationDelegate handleAppleEvent:withReplyEvent:] isn't getting triggered)...

A side note: I've honestly never hit Cmd-H in my life until today, and yet I'm pretty sure I've seen this bug before when trying to open links from Thunderbird.
(In reply to :Gijs Kruitbosch from comment #25)
> bug 996848 would fit the bill...

Thanks! I'm building before and after these changes now to either confirm it or rule it out.
(In reply to Stephen Pohl [:spohl] from comment #27)
> (In reply to :Gijs Kruitbosch from comment #25)
> > bug 996848 would fit the bill...
> 
> Thanks! I'm building before and after these changes now to either confirm it
> or rule it out.

I can confirm with near certainty that bug 996848 caused this. While clicking a link in an external app seemed to work consistently before bug 996848, the clicks only appear to work intermittently (~1 out of 5 times) after bug 996848.

n-i smichaud in case he has any immediate thoughts on what might be going on here.
Blocks: 996848
Flags: needinfo?(smichaud)
I currently have no idea what's going on here.  So I'll need to reproduce this bug *lots* times to find out (adding more and more logging between tries).  For this to be feasible, I *desperately* need better STR -- something that works at least 50% of the time.
Assignee: nobody → smichaud
Flags: needinfo?(smichaud)
What is a "Butler shortcut"?
Steven, the steps I used were:
1. Start Firefox
2. Hide with Cmd+H
3. Click on a link in Thunderbird.

The rate of reproducibility was 80% or better.
I tried that 5 or 6 times, and it *never* worked.

So ...

What versions of Firefox and Thunderbird, on which version of OS X?  (I tested on OS X 10.8.5 using the current release versions of Firefox and Thunderbird.)
OSX 10.9.5
Thunderbird 31.1.2
Firefox built off cset fc437fb80144: No issue
Firefox built off cset ac7542838773: Reproduced issue ~80% of the time
Stephen, did you just "mach build" your builds, or did you use a custom mozconfig?
Attached file mozconfig (deleted) — 
./mach build with this mozconfig
Stephen, could you do (and test) before and after builds for my patch for bug 1016200?

https://hg.mozilla.org/mozilla-central/rev/5f7e8306f31f

I made some adjustments to my patch for bug 996848 after it landed.  That was the last of them.
This was the patch that landed just before:

https://hg.mozilla.org/mozilla-central/rev/9abc7829bde3
(In reply to Steven Michaud)
> https://hg.mozilla.org/mozilla-central/rev/9abc7829bde3
> https://hg.mozilla.org/mozilla-central/rev/5f7e8306f31f

There doesn't seem to be a change in behavior between these two csets. The issue remains reproducible about 4 out of 5 times (or worse).
Just found *much* better STR, which (so far) works every time I've tried it:

1) Run Firefox, but first make sure it's *not* your default web browser.
2) Cmd-h to hide Firefox.
3) Run Thunderbird and click on a URL in some email message.

Stephen and others:  Please confirm (or not) that this works 100% of the time for you.  If it does, I'll add a comment to the whiteboard saying that the STR for this bug is in comment #39.
(In reply to Steven Michaud from comment #39)
> Just found *much* better STR, which (so far) works every time I've tried it:
> 
> 1) Run Firefox, but first make sure it's *not* your default web browser.
> 2) Cmd-h to hide Firefox.
> 3) Run Thunderbird and click on a URL in some email message.
> 
> Stephen and others:  Please confirm (or not) that this works 100% of the
> time for you.  If it does, I'll add a comment to the whiteboard saying that
> the STR for this bug is in comment #39.

This just opens Safari for me (which I'd set as my default per (1))? How does opening a link still open Firefox for you? :-\
Actually I found even the following seems to work 100% of the time:

1) Make sure either Firefox (betas and releases) or Nightly is your default browser.
2) Quit all running copies of Firefox and Thunderbird.
3) Run Firefox, then Cmd-h to hide it.
4) Run Thunderbird and click on a URL in some email message.
Those extra steps compared to the ones in comment 31 seem unnecessary. But I'm glad you were able to reproduce.
(In reply to :Gijs Kruitbosch from comment #40)
> (In reply to Steven Michaud from comment #39)
> > Just found *much* better STR, which (so far) works every time I've tried it:
> > 
> > 1) Run Firefox, but first make sure it's *not* your default web browser.
> > 2) Cmd-h to hide Firefox.
> > 3) Run Thunderbird and click on a URL in some email message.
> > 
> > Stephen and others:  Please confirm (or not) that this works 100% of the
> > time for you.  If it does, I'll add a comment to the whiteboard saying that
> > the STR for this bug is in comment #39.
> 
> This just opens Safari for me (which I'd set as my default per (1))? How
> does opening a link still open Firefox for you? :-\

This opens Safari for me as well.
>> 1) Run Firefox, but first make sure it's *not* your default web browser.
> ...
> This just opens Safari for me

I should have written my step 1 as follows:

"Make either Firefox or Nightly your default browser, then run the other."

But that's now beside the point, since my simpler steps from comment #41 work just as well.
Whiteboard: [STR in comment #41]
Testing with my STR from comment #41 also puts the blame on my patch for bug 996848 -- the bug doesn't happen in a build made with the patch just before it landed.

I'll be working on this, but it may not be until later this week, or possibly next week.
I'm thrilled it's in your queue!
> I'm thrilled it's in your queue!

Can't say I'm thrilled, exactly.  But I'm a strong believer in "you break it, you fix it", and I seem to have broken this :-(
Steven, thank you for working on this bug. This is a really annoying problem for many users in my org.
same problem in latest FF33.
Coming fopm Thunderbird 33 and also from other programs.
Problem ratio: 100% 

and as posted before: it's really an annoying problem
Same problem in Aurora 34.0a2 (2014-10-13) on Yosemite GM.

For me there is a timing issue: when Firefox just launched, opening links when Firefox is hidden works properly ; but when the app has been hidden for some time, or the computer went to sleep and woke up again, it breaks, and links don't open anymore.
(also I have this issue very consistently, on two different computers, for the past few weeks ; it looks compatible with the identified regression interval.)
I should be able to get to this next week.
> A side note: I've honestly never hit Cmd-H in my life until today,
> and yet I'm pretty sure I've seen this bug before when trying to
> open links from Thunderbird.

Just wanted to confirm this part. I never use Cmd-H or minimize and I've been seeing this regularly (but intermittently) from Thunderbird. I can reproduce it even if Firefox is visible but not the frontmost app.

With Cmd-H I can reproduce close to 100% of the time, though.

Thanks for working on this.
This is quite possibly the most annoying Firefox bug ever. Who do I payoff to fix this? ;-)
Any luck so far, Steven? Anything we can do to help? I'm basically having to open every web page twice over here.
Flags: needinfo?(smichaud)
Ditto. If you're swamped Steven (which is an acceptable state to be in), do you know who else might know this area of the code?
This is close to next on my list.  And I'm probably the only one who can fix it.
Flags: needinfo?(smichaud)
Attached patch Fix (deleted) — — Splinter Review 
This turns out to have an easy fix ... or at least I hope so.  At any rate this patch fixes the bug in my tests.

I've started a set of tryserver builds:
https://tbpl.mozilla.org/?tree=Try&rev=4de9a1135053

When a test build is ready, I'll post a link to it and ask that people here test it.
Here's a test build made with my patch from comment #59:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-4de9a1135053/try-macosx64/firefox-36.0a1.en-US.mac.dmg

Whoever sees this bug regularly, please test with it and let us know whether or not it fixes the bug.
Thanks Steven! Testing build now.
I clicked the link to this bug in my mail client, and it opened! Another 30 tries of various things shows no sign of the bug. Fixed for me! You've made my week, Steven.
Yup, fixed here as well. Thanks!
Attachment #8515100 - Flags: review?(spohl.mozilla.bugs)
Also fixed here.

You're the best, Steven.
Attachment #8515100 - Flags: review?(spohl.mozilla.bugs) → review+
Nightly 36.0a1 also finally, mercifully, fixes this issue 100% for me as well. Thank you very much!

Any idea how long before this patch makes it to the stable build?
Component: Tabbed Browser → Widget: Cocoa
Product: Firefox → Core
https://hg.mozilla.org/mozilla-central/rev/89282ba7eec9
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Iteration: --- → 36.2
Reproduced the initial issue using steps from comment 41 on an old Nightly (2014-09-29), verified using latest Nightly on Mac OS X 10.9.5 that the issue is fixed.
Status: RESOLVED → VERIFIED
status-firefox36: --- → verified
Needinfo as a reminder for uplift or setting status-firefox34/35 to wontfix.
Flags: needinfo?(smichaud)
Or other Stephen? Last beta build that isn't RC is today, so... :-)
Flags: needinfo?(spohl.mozilla.bugs)
Chatted with smichaud and he'll be taking care of this today.
Flags: needinfo?(spohl.mozilla.bugs)
Comment on attachment 8515100 [details] [diff] [review]
Fix

Approval Request Comment
[Feature/regressing bug #]: 996848
[User impact if declined]: Annoying UI bug
[Describe test coverage new/current, TBPL]: Baked on m-c for two weeks with no reported problems
[Risks and why]: Low.  Minor change to existing code.
[String/UUID change made/needed]: None
Flags: needinfo?(smichaud)
Attachment #8515100 - Flags: approval-mozilla-beta?
Attachment #8515100 - Flags: approval-mozilla-aurora?
Comment on attachment 8515100 [details] [diff] [review]
Fix

I think this is an edge case and, although irritating, given that we're at beta9, something that we can live with in 34 with the fix coming in 35. Beta-
Attachment #8515100 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Can you just clarify whether "edge case" refers to having Firefox hidden, or to opening links from outside Firefox? If the former, note that the bug description is actually inaccurate and that this applies to all links from external applications. It's possible that that still qualifies as an edge case with most people using webmail, etc., but for anyone who uses non-browser apps, this bug is incredibly annoying. I'm happy now that this is fixed in the dev builds, but this is actually the first Firefox bug in years that caused me to temporarily switch default browsers.
Lawrence, I can see where you're coming from, but for the people who are heavily affected by this, it is not an edgecase. It was tricky to find steps to reproduce it *all the time* for some of us (e.g. it seems to be working OK for me in beta), but where people had issues, it basically meant that opening links was hit and miss. That's a UX trust issue, and is pretty harmful. The fix is also very simple, and has had almost 2 weeks of baking on m-c now. I'd really like this to be reconsidered for beta.
Flags: needinfo?(lmandel)
Comment on attachment 8515100 [details] [diff] [review]
Fix

(In reply to Dan Stillman from comment #75)
> Can you just clarify whether "edge case" refers to having Firefox hidden, or
> to opening links from outside Firefox? If the former, note that the bug
> description is actually inaccurate and that this applies to all links from
> external applications. It's possible that that still qualifies as an edge
> case with most people using webmail, etc., but for anyone who uses
> non-browser apps, this bug is incredibly annoying. I'm happy now that this
> is fixed in the dev builds, but this is actually the first Firefox bug in
> years that caused me to temporarily switch default browsers.

I forgot to include a request to correct me if I've misunderstood the bug. Thank you for doing that anyway. By edge case I meant that Firefox had to be hidden. Given that this impacts ALL external applications I think this does warrant inclusion in 34. Glad that the patch is very small+simple so that I don't have to be overly concerned about risk of regression. Beta+
Flags: needinfo?(lmandel)
Attachment #8515100 - Flags: approval-mozilla-beta- → approval-mozilla-beta+
Attachment #8515100 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Summary: Links from external applications sometimes fail to open when Firefox is hidden → Links from external applications sometimes fail to open (especially when Firefox is hidden)
Reproduced with Nightly 2014-09-29.
Verified as fixed with Firefox 34 beta 10 (Build ID: 20141117202603) and latest Aurora 35.0a2 (Build ID: 20141118004001) on Mac OS X 10.9.5 using steps from comment 41.
status-firefox34: fixed → verified
status-firefox35: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: