Closed Bug 1319166 Opened 7 years ago Closed 5 years ago

Doing a build causes OS print dialog to pop up

Categories

(Firefox Build System :: General, defect)

53 Branch
x86_64
macOS
defect
Not set
normal

Tracking

(firefox53 affected)

RESOLVED FIXED
Tracking Status
firefox53 --- affected

People

(Reporter: kats, Assigned: gps)

References

Details

Attachments

(1 file)

I'm using iTerm2 Build 3.0.9 on OS X 10.11.6. Doing a regular build using |mach build| seems to now pop up a print dialog intermittently (looks the same as what I get if type Command+P). I strongly suspect this is a result of bug 1171610, with ANSI escape codes possibly being misinterpreted or incorrectly generated.

This is very annoying because it doesn't happen just once but a bunch of times, interrupting the build frequently and forcing me to repeatedly cancel the print dialog. The console output is also garbled at this point but it looks like it's building webrtc code, if that helps at all.

daleharvey also reported seeing this on IRC this morning.
mconley is also affected and reported the issue on 2016-11-17.
(In reply to Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout) from comment #1)
> mconley is also affected and reported the issue on 2016-11-17.

Where? I follow all the bug components where this should have been reported and this bug is the first I've seen of this issue. I'm mildly... irritated that there was an apparent 4 day lag between this issue being observed and it appearing in a Core :: Build Config bug.
Flags: needinfo?(mconley)
I reported it in #developers, but nobody seemed to be seeing the same thing (or at least didn't mention it to me), so I assumed my local copy of iTerm must have been improperly configured, and then I got distracted with other bugs, so I failed to file it. Sorry!
Flags: needinfo?(mconley)
Please ping a build peer next time. I can't find a reference to it, but I have recollections of this happening 3-4 years ago. Coloring is almost certainly the culprit.

The workaround is to add `-fdiagnostics-color=never` (GCC) or `-fcolor-diagnostics=never` (Clang) to your CFLAGS and CXXFLAGS variables in your mozconfig (strictly speaking there are other variables, but I doubt they are causing the problem).
Assignee: nobody → gps
Status: NEW → ASSIGNED
Keywords: leave-open
This happens when the sequence "ESC [ 2 i" is printed out. This can be reproduced with the following command:
  printf '\e[2i'

This can be disabled in prefs>profiles>terminal>Disable session-initiated printing.

I'm not sure if it's a "standard" escape sequence or one made up by iTerm, but it's not the first time this is reported:
https://gitlab.com/search?utf8=%E2%9C%93&search=print+dialog&group_id=&project_id=252461&scope=issues&repository_ref=

(and none of those were about building Firefox)

It's not documented on https://www.iterm2.com/documentation-escape-codes.html but I also can't find it documented in the various places where the "standard" escape sequences are documented.

I wonder what kind of terminal mixing can end up printing out this sequence... I guess there's some mix between a "ESC [ 2 m" (which unsets bold) and something printing an "i".

I'd rather not rush a workaround (that just disables the color output) out the door. Iterm2 users can disable session-initiated printing as an immediate "fix".
Comment on attachment 8812996 [details]
Bug 1319166 - Don't automatically enable color in iTerm2;

https://reviewboard.mozilla.org/r/94516/#review94820
Attachment #8812996 - Flags: review?(mh+mozilla) → review-
(In reply to Mike Hommey [:glandium] from comment #7)
> I'd rather not rush a workaround (that just disables the color output) out
> the door. Iterm2 users can disable session-initiated printing as an
> immediate "fix".

While I sympathize with this being apparent "odd" behavior by iTerm2, the end-user experience of seeing a print dialog when building Firefox is a truly WTF experience for those users. If I were a first-time contributor and this happened to me, I'm pretty sure I'd have a visceral negative reaction to the experience.

I'd prefer we play it safe and prevent this unexpected behavior altogether until we can figure out a proper workaround. I think avoiding the unwanted distraction of an unexpected print dialog is in the best interest of the average contributor.
The point is it happens with other things than Firefox, and is specific to iTerm2. I'm arguing iTerm2 can check a box that will solve the issue for them while a proper work around is found, and in the meanwhile, the OSX users that don't use iTerm2 can still benefit from colors.
(In reply to Mike Hommey [:glandium] from comment #10)
> I'm arguing iTerm2 can check a box (...)

s/iTerm2/iTerm2 users/
Apparently, iTerm2 sets TERM_PROGRAM to iTerm.app

https://gitlab.com/gnachman/iterm2/issues/3414

I'd take a patch that disables color for iTerm2 only.
Comment on attachment 8812996 [details]
Bug 1319166 - Don't automatically enable color in iTerm2;

https://reviewboard.mozilla.org/r/94516/#review94832

::: config/config.mk:364
(Diff revision 2)
>    LDFLAGS \
>    $(NULL)
>  
>  ifdef MACH_STDOUT_ISATTY
>  ifdef COLOR_CFLAGS
> +# TODO Bug 1319166 - Clang doesn't reset color state between newlines.

You should update the comment (and commit message) to reflect comment 7, because the newlines thing is probably not the whole story (if it were, how do you end up with "ESC [ 2 i"?)

::: config/config.mk:367
(Diff revision 2)
>  ifdef MACH_STDOUT_ISATTY
>  ifdef COLOR_CFLAGS
> +# TODO Bug 1319166 - Clang doesn't reset color state between newlines.
> +# This can lead to iTerm2 showing print dialogs. Don't enable color
> +# on iTerm2 until a workaround is in place.
> +ifneq ($(TERM_PROGRAM)$(CLANG_CXX),iTerm.app1)

It's probably safer to just not care whether it's clang. That'd make the test simpler.

GCC is not supported to build on OSX anyways.
Attachment #8812996 - Flags: review?(mh+mozilla) → review+
Pushed by gszorc@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bb32e325ac8e
Don't automatically enable color in iTerm2; r=glandium
Product: Core → Firefox Build System
The leave-open keyword is there and there is no activity for 6 months.
:gps, maybe it's time to close this bug?
Flags: needinfo?(gps)
Yeah, let's close this.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(gps)
Keywords: leave-open
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: