• 
      

    Fix word wrapping in review request details fields.

    Review Request #5951 — Created June 7, 2014 and submitted

    Information

    Review Board
    release-2.0.x
    2652463...

    Reviewers

    Long strings in the review request details fields (on the right-hand side of
    the fields) would increase the width of the entire table, eventually
    overlapping the main fields in a very ugly way. This change adds a max-width to
    the field spans, and specifies a word-wrap to force browsers to insert line
    breaks in the middle of words in the case that it can't break at a natural
    place.

    • Set a branch that was just one long unbroken string of characters and saw it
      wrap at the width of the details pane.
    • Checked that a bunch of comma-separated bug numbers still wrapped at an ideal
      place in the text.
    Description From Last Updated

    Where does 12em come from? Does anything else use it? We should make this a constant somewhere.

    chipx86chipx86

    Can you add a comment saying that any changes to this need to be reflected in _resizeLayout in reviewRequestEditorView.js?

    chipx86chipx86

    Can we stick with: /* * this multi-line * comment format? */

    chipx86chipx86

    We should fetch the tbody first, and do further filters from that.

    chipx86chipx86

    How does this look if the value is wrapped to the following line?

    chipx86chipx86
    reviewbot
    1. This is a review from Review Bot.
        Tool: PEP8 Style Checker
        Processed Files:
        Ignored Files:
          reviewboard/static/rb/css/reviews.less
      
      
    2. 
        
    reviewbot
    1. This is a review from Review Bot.
        Tool: Pyflakes
        Processed Files:
        Ignored Files:
          reviewboard/static/rb/css/reviews.less
      
      
    2. 
        
    chipx86
    1. 
        
    2. reviewboard/static/rb/css/reviews.less (Diff revision 1)
       
       
      Show all issues

      Where does 12em come from? Does anything else use it?

      We should make this a constant somewhere.

      1. It's really just something I reverse engineered. There's no good way to determine the width of the second column without computing it at runtime in javascript.

      2. Silly CSS :(

        Since the span is in the second column of the table, it should be constrained to that <td> anyway. The real problem is if the details table gets wider with more content. I think, instead of setting the max-width of the span, we should just be able to set the max width of the table itself.

        That'll be necessary when there's custom columns with labels wider than what we use by default as well, or when dealing with localization.

      3. Setting a max-width on the table doesn't work. :(

      4. What if you put the table in a container element that has max-width?

        I remember tables are pretty weird in how they handle things like min/max. Again, silly CSS...

      5. I'll keep poking but initial experiments are less than promising.

      6. After banging my head on this for the last week, I'm going to say the hard-coded 12em is the least bad solution =/

      7. Okay. I'm going to want to play with it a bit too, but failing that, the 12em sounds okay..

    3. 
        
    david
    reviewbot
    1. Tool: PEP8 Style Checker
      Ignored Files:
          reviewboard/static/rb/css/reviews.less
          reviewboard/static/rb/js/views/reviewRequestEditorView.js
      
      
      
      Tool: Pyflakes
      Ignored Files:
          reviewboard/static/rb/css/reviews.less
          reviewboard/static/rb/js/views/reviewRequestEditorView.js
      
      
    2. 
        
    chipx86
    1. 
        
    2. reviewboard/static/rb/css/reviews.less (Diff revision 2)
       
       
      Show all issues

      Can you add a comment saying that any changes to this need to be reflected in _resizeLayout in reviewRequestEditorView.js?

    3. Show all issues

      We should fetch the tbody first, and do further filters from that.

    4. Show all issues

      How does this look if the value is wrapped to the following line?

      1. Just as bad? Maybe worse.

    5. 
        
    david
    reviewbot
    1. Tool: PEP8 Style Checker
      Ignored Files:
          reviewboard/static/rb/css/reviews.less
          reviewboard/static/rb/js/views/reviewRequestEditorView.js
      
      
      
      Tool: Pyflakes
      Ignored Files:
          reviewboard/static/rb/css/reviews.less
          reviewboard/static/rb/js/views/reviewRequestEditorView.js
      
      
    2. 
        
    chipx86
    1. 
        
    2. reviewboard/static/rb/css/reviews.less (Diff revisions 2 - 3)
       
       
       
      Show all issues

      Can we stick with:

      /*
       * this multi-line
       * comment format?
       */
      
    3. 
        
    david
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to release-2.0.x (c6205d8)